From 5c5d0fef19da3483c786b4423ca8f25b2fda7873 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 20 Sep 2024 17:47:26 +0200 Subject: [PATCH] pull out modifications for fairmat-2024-nxaperture --- applications/NXapm.nxdl.xml | 1104 --------- applications/NXarpes.nxdl.xml | 9 +- applications/NXellipsometry.nxdl.xml | 422 ---- applications/NXem.nxdl.xml | 1663 -------------- applications/NXmpes.nxdl.xml | 918 -------- applications/NXmpes_arpes.nxdl.xml | 417 ---- applications/NXoptical_spectroscopy.nxdl.xml | 1218 ---------- applications/NXraman.nxdl.xml | 261 --- applications/NXxps.nxdl.xml | 510 ----- applications/xps/xps_cs.png | Bin 148952 -> 0 bytes base_classes/NXactuator.nxdl.xml | 127 - .../NXapm_charge_state_analysis.nxdl.xml | 168 -- base_classes/NXapm_hit_finding.nxdl.xml | 147 -- base_classes/NXapm_msr.nxdl.xml | 173 -- 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/NXbeam.nxdl.xml | 157 +- base_classes/NXbeam_device.nxdl.xml | 67 - .../NXbeam_transfer_matrix_table.nxdl.xml | 120 - base_classes/NXcalibration.nxdl.xml | 220 -- .../NXcg_face_list_data_structure.nxdl.xml | 230 -- base_classes/NXcg_hexahedron_set.nxdl.xml | 193 -- base_classes/NXcg_parallelogram_set.nxdl.xml | 106 - base_classes/NXcg_point_set.nxdl.xml | 87 - base_classes/NXcg_polygon_set.nxdl.xml | 131 -- base_classes/NXcg_polyhedron_set.nxdl.xml | 114 - base_classes/NXcg_primitive_set.nxdl.xml | 212 -- base_classes/NXcg_roi_set.nxdl.xml | 57 - base_classes/NXcg_tetrahedron_set.nxdl.xml | 86 - base_classes/NXcg_triangle_set.nxdl.xml | 97 - base_classes/NXchemical_process.nxdl.xml | 60 - base_classes/NXcircuit.nxdl.xml | 136 -- base_classes/NXcomponent.nxdl.xml | 64 - base_classes/NXcoordinate_system.nxdl.xml | 159 -- base_classes/NXcoordinate_system_set.nxdl.xml | 240 -- base_classes/NXcorrector_cs.nxdl.xml | 221 -- base_classes/NXcrystal_structure.nxdl.xml | 274 --- base_classes/NXcs_computer.nxdl.xml | 146 -- base_classes/NXdata.nxdl.xml | 55 - base_classes/NXdetector.nxdl.xml | 60 +- base_classes/NXelectron_level.nxdl.xml | 918 -------- base_classes/NXelectronanalyser.nxdl.xml | 310 --- base_classes/NXem_correlation.nxdl.xml | 245 -- base_classes/NXem_ebsd.nxdl.xml | 712 ------ base_classes/NXem_eds.nxdl.xml | 225 -- base_classes/NXem_eels.nxdl.xml | 63 - base_classes/NXem_img.nxdl.xml | 61 - base_classes/NXem_msr.nxdl.xml | 98 - base_classes/NXem_sim.nxdl.xml | 59 - base_classes/NXenergydispersion.nxdl.xml | 209 -- base_classes/NXentry.nxdl.xml | 60 +- base_classes/NXenvironment.nxdl.xml | 38 +- base_classes/NXevent_data_apm.nxdl.xml | 281 --- base_classes/NXevent_data_apm_set.nxdl.xml | 48 - base_classes/NXevent_data_em.nxdl.xml | 168 -- base_classes/NXevent_data_em_set.nxdl.xml | 49 - base_classes/NXfabrication.nxdl.xml | 70 - base_classes/NXfit.nxdl.xml | 199 -- base_classes/NXfit_background.nxdl.xml | 80 - base_classes/NXfit_function.nxdl.xml | 47 - base_classes/NXhistory.nxdl.xml | 74 - base_classes/NXimage_set.nxdl.xml | 652 ------ base_classes/NXinstrument.nxdl.xml | 5 - base_classes/NXinteraction_vol_em.nxdl.xml | 57 - base_classes/NXion.nxdl.xml | 158 -- base_classes/NXlens_em.nxdl.xml | 96 - base_classes/NXmanipulator.nxdl.xml | 257 --- base_classes/NXmonochromator.nxdl.xml | 21 +- base_classes/NXopt_window.nxdl.xml | 128 -- base_classes/NXoptical_system_em.nxdl.xml | 155 -- base_classes/NXpeak.nxdl.xml | 86 - base_classes/NXphysical_process.nxdl.xml | 61 - base_classes/NXprocess.nxdl.xml | 16 +- base_classes/NXprocess_mpes.nxdl.xml | 317 --- base_classes/NXpulser_apm.nxdl.xml | 238 -- base_classes/NXreflectron.nxdl.xml | 86 - base_classes/NXresolution.nxdl.xml | 125 - base_classes/NXroot.nxdl.xml | 31 +- base_classes/NXrotation_set.nxdl.xml | 256 --- base_classes/NXsample.nxdl.xml | 68 +- base_classes/NXsample_component.nxdl.xml | 51 +- base_classes/NXsample_component_set.nxdl.xml | 78 - base_classes/NXscanbox_em.nxdl.xml | 111 - base_classes/NXsensor.nxdl.xml | 3 +- base_classes/NXserialized.nxdl.xml | 74 - base_classes/NXsingle_crystal.nxdl.xml | 72 - base_classes/NXsource.nxdl.xml | 152 +- base_classes/NXspectrum_set.nxdl.xml | 559 ----- base_classes/NXstage_lab.nxdl.xml | 173 -- base_classes/NXsubentry.nxdl.xml | 9 +- base_classes/NXsubstance.nxdl.xml | 119 - base_classes/NXtransformations.nxdl.xml | 9 +- base_classes/NXuser.nxdl.xml | 16 +- .../NXaberration.nxdl.xml | 44 +- .../NXaberration_model.nxdl.xml | 105 + .../NXaberration_model_ceos.nxdl.xml | 91 + .../NXaberration_model_nion.nxdl.xml | 63 + .../NXadc.nxdl.xml | 20 +- contributed_definitions/NXamplifier.nxdl.xml | 91 - .../NXaperture_em.nxdl.xml | 37 +- contributed_definitions/NXapm.nxdl.xml | 1696 ++++++++++++++ .../NXapm_composition_space_results.nxdl.xml | 488 ++++ .../NXapm_compositionspace_config.nxdl.xml | 191 -- .../NXapm_compositionspace_results.nxdl.xml | 390 ---- .../NXapm_input_ranging.nxdl.xml | 63 + .../NXapm_input_reconstruction.nxdl.xml | 58 + .../NXapm_paraprobe_clusterer_config.nxdl.xml | 384 ---- ...NXapm_paraprobe_clusterer_results.nxdl.xml | 299 --- .../NXapm_paraprobe_config_clusterer.nxdl.xml | 477 ++++ .../NXapm_paraprobe_config_distancer.nxdl.xml | 257 +++ ...Xapm_paraprobe_config_intersector.nxdl.xml | 348 +++ .../NXapm_paraprobe_config_nanochem.nxdl.xml | 1114 +++++++++ .../NXapm_paraprobe_config_ranger.nxdl.xml | 297 +++ .../NXapm_paraprobe_config_selector.nxdl.xml | 142 ++ .../NXapm_paraprobe_config_spatstat.nxdl.xml | 374 +++ .../NXapm_paraprobe_config_surfacer.nxdl.xml | 289 +++ ...Xapm_paraprobe_config_tessellator.nxdl.xml | 253 ++ ...NXapm_paraprobe_config_transcoder.nxdl.xml | 119 + .../NXapm_paraprobe_distancer_config.nxdl.xml | 202 -- ...NXapm_paraprobe_distancer_results.nxdl.xml | 202 -- ...Xapm_paraprobe_intersector_config.nxdl.xml | 278 --- ...apm_paraprobe_intersector_results.nxdl.xml | 274 --- .../NXapm_paraprobe_nanochem_config.nxdl.xml | 1040 --------- .../NXapm_paraprobe_nanochem_results.nxdl.xml | 1272 ----------- .../NXapm_paraprobe_ranger_config.nxdl.xml | 245 -- .../NXapm_paraprobe_ranger_results.nxdl.xml | 139 -- ...NXapm_paraprobe_results_clusterer.nxdl.xml | 503 ++++ ...NXapm_paraprobe_results_distancer.nxdl.xml | 388 ++++ ...apm_paraprobe_results_intersector.nxdl.xml | 395 ++++ .../NXapm_paraprobe_results_nanochem.nxdl.xml | 1965 ++++++++++++++++ .../NXapm_paraprobe_results_ranger.nxdl.xml | 425 ++++ .../NXapm_paraprobe_results_selector.nxdl.xml | 274 +++ .../NXapm_paraprobe_results_spatstat.nxdl.xml | 364 +++ .../NXapm_paraprobe_results_surfacer.nxdl.xml | 503 ++++ ...apm_paraprobe_results_tessellator.nxdl.xml | 677 ++++++ ...Xapm_paraprobe_results_transcoder.nxdl.xml | 568 +++++ .../NXapm_paraprobe_selector_config.nxdl.xml | 125 - .../NXapm_paraprobe_selector_results.nxdl.xml | 111 - .../NXapm_paraprobe_spatstat_config.nxdl.xml | 338 --- .../NXapm_paraprobe_spatstat_results.nxdl.xml | 200 -- .../NXapm_paraprobe_surfacer_config.nxdl.xml | 235 -- .../NXapm_paraprobe_surfacer_results.nxdl.xml | 289 --- ...Xapm_paraprobe_tessellator_config.nxdl.xml | 175 -- ...apm_paraprobe_tessellator_results.nxdl.xml | 337 --- .../NXapm_paraprobe_tool_common.nxdl.xml | 129 -- .../NXapm_paraprobe_tool_config.nxdl.xml | 137 -- .../NXapm_paraprobe_tool_results.nxdl.xml | 87 - ...NXapm_paraprobe_transcoder_config.nxdl.xml | 83 - ...Xapm_paraprobe_transcoder_results.nxdl.xml | 219 -- contributed_definitions/NXatom_set.nxdl.xml | 158 -- .../NXbias_spectroscopy.nxdl.xml | 168 -- .../NXcalibration.nxdl.xml | 111 + .../NXcg_alpha_complex.nxdl.xml | 113 +- .../NXcg_cylinder_set.nxdl.xml | 130 +- .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_face_list_data_structure.nxdl.xml | 243 ++ .../NXcg_geodesic_mesh.nxdl.xml | 42 +- .../NXcg_grid.nxdl.xml | 92 +- .../NXcg_half_edge_data_structure.nxdl.xml | 98 +- .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_marching_cubes.nxdl.xml | 54 +- .../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_polyline_set.nxdl.xml | 123 +- contributed_definitions/NXcg_roi_set.nxdl.xml | 40 + .../NXcg_sphere_set.nxdl.xml | 121 + .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcg_triangulated_surface_mesh.nxdl.xml | 61 +- .../NXcg_unit_normal_set.nxdl.xml | 31 +- .../NXchamber.nxdl.xml | 17 +- .../NXchemical_composition.nxdl.xml | 0 .../NXcircuit_board.nxdl.xml | 45 + contributed_definitions/NXclustering.nxdl.xml | 124 + .../NXcollectioncolumn.nxdl.xml | 46 +- .../NXcoordinate_system_set.nxdl.xml | 137 ++ .../NXcorrector_cs.nxdl.xml | 95 + .../NXcs_computer.nxdl.xml | 80 + contributed_definitions/NXcs_cpu.nxdl.xml | 39 + .../NXcs_filter_boolean_mask.nxdl.xml | 68 +- contributed_definitions/NXcs_gpu.nxdl.xml | 39 + .../NXcs_io_obj.nxdl.xml | 41 +- .../NXcs_io_sys.nxdl.xml | 22 +- .../NXcs_mm_sys.nxdl.xml | 30 +- .../NXcs_prng.nxdl.xml | 58 +- .../NXcs_profiling.nxdl.xml | 68 +- .../NXcs_profiling_event.nxdl.xml | 27 +- contributed_definitions/NXdac.nxdl.xml | 38 + contributed_definitions/NXdata_mpes.nxdl.xml | 134 -- .../NXdata_mpes_detector.nxdl.xml | 147 -- .../NXdeflector.nxdl.xml | 50 +- .../NXdelocalization.nxdl.xml | 164 +- .../NXdispersive_material.nxdl.xml | 11 +- .../NXdistortion.nxdl.xml | 0 .../NXebeam_column.nxdl.xml | 72 +- .../NXelectronanalyser.nxdl.xml | 157 ++ .../NXellipsometry.nxdl.xml | 357 +++ contributed_definitions/NXem.nxdl.xml | 2034 +++++++++++++++++ .../NXem_calorimetry.nxdl.xml | 299 --- contributed_definitions/NXem_ebsd.nxdl.xml | 1926 ++++++++++++++++ .../NXem_ebsd_conventions.nxdl.xml | 610 +++++ ...NXem_ebsd_crystal_structure_model.nxdl.xml | 207 +- .../NXenergydispersion.nxdl.xml | 90 + .../NXevent_data_em.nxdl.xml | 226 ++ .../NXevent_data_em_set.nxdl.xml | 18 +- .../NXfabrication.nxdl.xml | 37 +- .../NXgraph_edge_set.nxdl.xml | 56 +- .../NXgraph_node_set.nxdl.xml | 81 +- contributed_definitions/NXgraph_root.nxdl.xml | 5 +- .../NXibeam_column.nxdl.xml | 95 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++ .../NXimage_set_em_adf.nxdl.xml | 156 ++ .../NXimage_set_em_kikuchi.nxdl.xml | 205 ++ .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXion.nxdl.xml | 168 ++ contributed_definitions/NXisocontour.nxdl.xml | 41 +- contributed_definitions/NXiv_bias.nxdl.xml | 192 -- contributed_definitions/NXiv_temp.nxdl.xml | 19 - ...ctro_chemo_mechanical_preparation.nxdl.xml | 6 +- .../NXlab_sample_mounting.nxdl.xml | 6 +- contributed_definitions/NXlens_em.nxdl.xml | 109 + .../NXlens_opt.nxdl.xml | 23 +- contributed_definitions/NXlockin.nxdl.xml | 151 -- .../NXmanipulator.nxdl.xml | 100 + .../NXmatch_filter.nxdl.xml | 23 +- .../NXmicrostructure.nxdl.xml | 776 ------- .../NXmicrostructure_gragles_config.nxdl.xml | 369 --- .../NXmicrostructure_gragles_results.nxdl.xml | 295 --- .../NXmicrostructure_imm_config.nxdl.xml | 244 -- .../NXmicrostructure_imm_results.nxdl.xml | 189 -- .../NXmicrostructure_ipf.nxdl.xml | 243 -- .../NXmicrostructure_kanapy_results.nxdl.xml | 193 -- .../NXmicrostructure_mtex_config.nxdl.xml | 321 --- .../NXmicrostructure_odf.nxdl.xml | 224 -- .../NXmicrostructure_pf.nxdl.xml | 114 - .../NXmicrostructure_score_results.nxdl.xml | 543 ----- contributed_definitions/NXmpes.nxdl.xml | 371 +++ contributed_definitions/NXms.nxdl.xml | 529 +++++ .../NXms_feature_set.nxdl.xml | 300 +++ ...ig.nxdl.xml => NXms_score_config.nxdl.xml} | 368 ++- .../NXms_score_results.nxdl.xml | 720 ++++++ .../NXms_snapshot.nxdl.xml | 47 +- .../NXms_snapshot_set.nxdl.xml | 62 + contributed_definitions/NXopt.nxdl.xml | 868 +++++++ .../NXoptical_system_em.nxdl.xml | 83 + .../NXorientation_set.nxdl.xml | 133 ++ contributed_definitions/NXpeak.nxdl.xml | 87 + .../NXpid.nxdl.xml | 35 +- .../NXpositioner_sts.nxdl.xml | 310 --- .../NXprogram.nxdl.xml | 0 contributed_definitions/NXpulser_apm.nxdl.xml | 166 ++ .../NXpump.nxdl.xml | 12 +- contributed_definitions/NXreflectron.nxdl.xml | 56 + .../NXregistration.nxdl.xml | 0 contributed_definitions/NXscanbox_em.nxdl.xml | 47 + .../NXsensor_scan.nxdl.xml | 12 +- contributed_definitions/NXsensor_sts.nxdl.xml | 233 -- .../NXsimilarity_grouping.nxdl.xml | 97 +- ...em.nxdl.xml => NXslip_system_set.nxdl.xml} | 29 +- .../NXspatial_filter.nxdl.xml | 76 +- .../NXspectrum_set.nxdl.xml | 162 ++ .../NXspectrum_set_em_eels.nxdl.xml | 188 ++ .../NXspectrum_set_em_xray.nxdl.xml | 311 +++ .../NXspindispersion.nxdl.xml | 0 contributed_definitions/NXstage_lab.nxdl.xml | 173 ++ contributed_definitions/NXsts.nxdl.xml | 995 -------- .../NXsubsampling_filter.nxdl.xml | 30 +- .../NXtransmission.nxdl.xml | 25 +- .../NXwaveplate.nxdl.xml | 12 +- contributed_definitions/NXxrd.nxdl.xml | 99 - contributed_definitions/NXxrd_pan.nxdl.xml | 335 --- dev_tools/docs/anchor_list.py | 4 - dev_tools/docs/nxdl.py | 24 +- dev_tools/docs/nxdl_index.py | 40 +- dev_tools/tests/test_nxdl_utils.py | 165 -- dev_tools/utils/nxdl_utils.py | 196 +- .../classes/applications/apm-structure.rst | 284 --- .../container/ComplexContainerBeampath.png | Bin 7089 -> 0 bytes .../container/ComplexExampleContainer.png | Bin 25103 -> 0 bytes .../classes/applications/em-structure.rst | 164 -- .../classes/applications/mpes-structure.rst | 42 - .../optical-spectroscopy-structure.rst | 199 -- .../classes/base_classes/apm-structure.rst | 284 --- .../container/ComplexContainerBeampath.png | Bin 7089 -> 0 bytes .../container/ComplexExampleContainer.png | Bin 25103 -> 0 bytes .../classes/base_classes/em-structure.rst | 164 -- .../classes/base_classes/mpes-structure.rst | 77 - .../optical-spectroscopy-structure.rst | 199 -- .../contributed_definitions/apm-structure.rst | 398 ++-- .../cgms-structure.rst | 269 ++- .../container/ComplexContainerBeampath.png | Bin 7089 -> 0 bytes .../container/ComplexExampleContainer.png | Bin 25103 -> 0 bytes ...ructure.rst => ellipsometry-structure.rst} | 74 +- .../contributed_definitions/em-structure.rst | 159 +- .../icme-structure.rst | 48 - .../mpes-structure.rst | 27 +- .../sample-prep-structure.rst | 20 - .../contributed_definitions/sts-structure.rst | 47 - .../transport-structure.rst | 10 +- 302 files changed, 27382 insertions(+), 36928 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXellipsometry.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 applications/NXmpes.nxdl.xml delete mode 100644 applications/NXmpes_arpes.nxdl.xml delete mode 100644 applications/NXoptical_spectroscopy.nxdl.xml delete mode 100644 applications/NXraman.nxdl.xml delete mode 100644 applications/NXxps.nxdl.xml delete mode 100644 applications/xps/xps_cs.png delete mode 100644 base_classes/NXactuator.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/NXbeam_device.nxdl.xml delete mode 100644 base_classes/NXbeam_transfer_matrix_table.nxdl.xml delete mode 100644 base_classes/NXcalibration.nxdl.xml delete mode 100644 base_classes/NXcg_face_list_data_structure.nxdl.xml delete mode 100644 base_classes/NXcg_hexahedron_set.nxdl.xml delete mode 100644 base_classes/NXcg_parallelogram_set.nxdl.xml delete mode 100644 base_classes/NXcg_point_set.nxdl.xml delete mode 100644 base_classes/NXcg_polygon_set.nxdl.xml delete mode 100644 base_classes/NXcg_polyhedron_set.nxdl.xml delete mode 100644 base_classes/NXcg_primitive_set.nxdl.xml delete mode 100644 base_classes/NXcg_roi_set.nxdl.xml delete mode 100644 base_classes/NXcg_tetrahedron_set.nxdl.xml delete mode 100644 base_classes/NXcg_triangle_set.nxdl.xml delete mode 100644 base_classes/NXchemical_process.nxdl.xml delete mode 100644 base_classes/NXcircuit.nxdl.xml delete mode 100644 base_classes/NXcomponent.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/NXelectron_level.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_eds.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_msr.nxdl.xml delete mode 100644 base_classes/NXem_sim.nxdl.xml delete mode 100644 base_classes/NXenergydispersion.nxdl.xml mode change 100644 => 100755 base_classes/NXentry.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/NXfit.nxdl.xml delete mode 100644 base_classes/NXfit_background.nxdl.xml delete mode 100644 base_classes/NXfit_function.nxdl.xml delete mode 100644 base_classes/NXhistory.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/NXmanipulator.nxdl.xml delete mode 100644 base_classes/NXopt_window.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/NXphysical_process.nxdl.xml delete mode 100644 base_classes/NXprocess_mpes.nxdl.xml delete mode 100644 base_classes/NXpulser_apm.nxdl.xml delete mode 100644 base_classes/NXreflectron.nxdl.xml delete mode 100644 base_classes/NXresolution.nxdl.xml delete mode 100644 base_classes/NXrotation_set.nxdl.xml mode change 100644 => 100755 base_classes/NXsample.nxdl.xml delete mode 100644 base_classes/NXsample_component_set.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXserialized.nxdl.xml delete mode 100644 base_classes/NXsingle_crystal.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/NXsubstance.nxdl.xml rename {base_classes => contributed_definitions}/NXaberration.nxdl.xml (62%) create mode 100644 contributed_definitions/NXaberration_model.nxdl.xml create mode 100644 contributed_definitions/NXaberration_model_ceos.nxdl.xml create mode 100644 contributed_definitions/NXaberration_model_nion.nxdl.xml rename base_classes/NXcg_triangulated_surface_mesh.nxdl.xml => contributed_definitions/NXadc.nxdl.xml (67%) delete mode 100644 contributed_definitions/NXamplifier.nxdl.xml rename base_classes/NXactivity.nxdl.xml => contributed_definitions/NXaperture_em.nxdl.xml (53%) create mode 100644 contributed_definitions/NXapm.nxdl.xml create mode 100644 contributed_definitions/NXapm_composition_space_results.nxdl.xml delete mode 100644 contributed_definitions/NXapm_compositionspace_config.nxdl.xml delete mode 100644 contributed_definitions/NXapm_compositionspace_results.nxdl.xml create mode 100644 contributed_definitions/NXapm_input_ranging.nxdl.xml create mode 100644 contributed_definitions/NXapm_input_reconstruction.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml delete mode 100644 contributed_definitions/NXatom_set.nxdl.xml delete mode 100644 contributed_definitions/NXbias_spectroscopy.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml rename {base_classes => contributed_definitions}/NXcg_alpha_complex.nxdl.xml (57%) rename {base_classes => contributed_definitions}/NXcg_cylinder_set.nxdl.xml (51%) create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml rename {base_classes => contributed_definitions}/NXcg_geodesic_mesh.nxdl.xml (58%) rename {base_classes => contributed_definitions}/NXcg_grid.nxdl.xml (60%) rename {base_classes => contributed_definitions}/NXcg_half_edge_data_structure.nxdl.xml (62%) create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml rename {base_classes => contributed_definitions}/NXcg_marching_cubes.nxdl.xml (54%) 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 rename {base_classes => contributed_definitions}/NXcg_polyline_set.nxdl.xml (51%) create mode 100644 contributed_definitions/NXcg_roi_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml rename base_classes/NXcg_ellipsoid_set.nxdl.xml => contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml (50%) rename {base_classes => contributed_definitions}/NXcg_unit_normal_set.nxdl.xml (71%) rename {base_classes => contributed_definitions}/NXchamber.nxdl.xml (76%) rename {base_classes => contributed_definitions}/NXchemical_composition.nxdl.xml (100%) create mode 100644 contributed_definitions/NXcircuit_board.nxdl.xml create mode 100644 contributed_definitions/NXclustering.nxdl.xml rename {base_classes => contributed_definitions}/NXcollectioncolumn.nxdl.xml (73%) 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_cpu.nxdl.xml rename {base_classes => contributed_definitions}/NXcs_filter_boolean_mask.nxdl.xml (53%) create mode 100644 contributed_definitions/NXcs_gpu.nxdl.xml rename base_classes/NXidentifier.nxdl.xml => contributed_definitions/NXcs_io_obj.nxdl.xml (55%) rename base_classes/NXroi.nxdl.xml => contributed_definitions/NXcs_io_sys.nxdl.xml (75%) rename base_classes/NXem_method.nxdl.xml => contributed_definitions/NXcs_mm_sys.nxdl.xml (57%) rename {base_classes => contributed_definitions}/NXcs_prng.nxdl.xml (62%) rename {base_classes => contributed_definitions}/NXcs_profiling.nxdl.xml (72%) rename {base_classes => contributed_definitions}/NXcs_profiling_event.nxdl.xml (82%) create mode 100644 contributed_definitions/NXdac.nxdl.xml delete mode 100644 contributed_definitions/NXdata_mpes.nxdl.xml delete mode 100644 contributed_definitions/NXdata_mpes_detector.nxdl.xml rename {base_classes => contributed_definitions}/NXdeflector.nxdl.xml (77%) rename {base_classes => contributed_definitions}/NXdistortion.nxdl.xml (100%) rename {base_classes => contributed_definitions}/NXebeam_column.nxdl.xml (59%) create mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/NXellipsometry.nxdl.xml create mode 100644 contributed_definitions/NXem.nxdl.xml delete mode 100644 contributed_definitions/NXem_calorimetry.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd_conventions.nxdl.xml rename base_classes/NXunit_cell.nxdl.xml => contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml (54%) create mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml rename base_classes/NXapm_sim.nxdl.xml => contributed_definitions/NXevent_data_em_set.nxdl.xml (71%) rename base_classes/NXfit_parameter.nxdl.xml => contributed_definitions/NXfabrication.nxdl.xml (56%) rename {base_classes => contributed_definitions}/NXibeam_column.nxdl.xml (57%) create mode 100644 contributed_definitions/NXimage_set.nxdl.xml create mode 100644 contributed_definitions/NXimage_set_em_adf.nxdl.xml create mode 100644 contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml delete mode 100644 contributed_definitions/NXiv_bias.nxdl.xml create mode 100644 contributed_definitions/NXlens_em.nxdl.xml rename {base_classes => contributed_definitions}/NXlens_opt.nxdl.xml (92%) delete mode 100644 contributed_definitions/NXlockin.nxdl.xml create mode 100644 contributed_definitions/NXmanipulator.nxdl.xml delete mode 100644 contributed_definitions/NXmicrostructure.nxdl.xml delete mode 100644 contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml delete mode 100644 contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml delete mode 100644 contributed_definitions/NXmicrostructure_imm_config.nxdl.xml delete mode 100644 contributed_definitions/NXmicrostructure_imm_results.nxdl.xml delete mode 100644 contributed_definitions/NXmicrostructure_ipf.nxdl.xml delete mode 100644 contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml delete mode 100644 contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml delete mode 100644 contributed_definitions/NXmicrostructure_odf.nxdl.xml delete mode 100644 contributed_definitions/NXmicrostructure_pf.nxdl.xml delete mode 100644 contributed_definitions/NXmicrostructure_score_results.nxdl.xml create mode 100644 contributed_definitions/NXmpes.nxdl.xml create mode 100644 contributed_definitions/NXms.nxdl.xml create mode 100644 contributed_definitions/NXms_feature_set.nxdl.xml rename contributed_definitions/{NXmicrostructure_score_config.nxdl.xml => NXms_score_config.nxdl.xml} (53%) create mode 100644 contributed_definitions/NXms_score_results.nxdl.xml rename base_classes/NXcg_sphere_set.nxdl.xml => contributed_definitions/NXms_snapshot.nxdl.xml (54%) create mode 100644 contributed_definitions/NXms_snapshot_set.nxdl.xml create mode 100644 contributed_definitions/NXopt.nxdl.xml create mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml create mode 100644 contributed_definitions/NXorientation_set.nxdl.xml create mode 100644 contributed_definitions/NXpeak.nxdl.xml rename {base_classes => contributed_definitions}/NXpid.nxdl.xml (70%) delete mode 100644 contributed_definitions/NXpositioner_sts.nxdl.xml rename {base_classes => contributed_definitions}/NXprogram.nxdl.xml (100%) create mode 100644 contributed_definitions/NXpulser_apm.nxdl.xml rename {base_classes => contributed_definitions}/NXpump.nxdl.xml (88%) create mode 100644 contributed_definitions/NXreflectron.nxdl.xml rename {base_classes => contributed_definitions}/NXregistration.nxdl.xml (100%) create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml delete mode 100644 contributed_definitions/NXsensor_sts.nxdl.xml rename contributed_definitions/{NXmicrostructure_slip_system.nxdl.xml => NXslip_system_set.nxdl.xml} (79%) create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set_em_eels.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set_em_xray.nxdl.xml rename {base_classes => contributed_definitions}/NXspindispersion.nxdl.xml (100%) create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml delete mode 100644 contributed_definitions/NXsts.nxdl.xml rename {base_classes => contributed_definitions}/NXwaveplate.nxdl.xml (95%) delete mode 100644 contributed_definitions/NXxrd.nxdl.xml delete mode 100644 contributed_definitions/NXxrd_pan.nxdl.xml mode change 100755 => 100644 dev_tools/docs/nxdl.py delete mode 100644 manual/source/classes/applications/apm-structure.rst delete mode 100644 manual/source/classes/applications/container/ComplexContainerBeampath.png delete mode 100644 manual/source/classes/applications/container/ComplexExampleContainer.png delete mode 100644 manual/source/classes/applications/em-structure.rst delete mode 100644 manual/source/classes/applications/mpes-structure.rst delete mode 100644 manual/source/classes/applications/optical-spectroscopy-structure.rst delete mode 100644 manual/source/classes/base_classes/apm-structure.rst delete mode 100644 manual/source/classes/base_classes/container/ComplexContainerBeampath.png delete mode 100644 manual/source/classes/base_classes/container/ComplexExampleContainer.png delete mode 100644 manual/source/classes/base_classes/em-structure.rst delete mode 100644 manual/source/classes/base_classes/mpes-structure.rst delete mode 100644 manual/source/classes/base_classes/optical-spectroscopy-structure.rst delete mode 100644 manual/source/classes/contributed_definitions/container/ComplexContainerBeampath.png delete mode 100644 manual/source/classes/contributed_definitions/container/ComplexExampleContainer.png rename manual/source/classes/contributed_definitions/{optical-spectroscopy-structure.rst => ellipsometry-structure.rst} (72%) delete mode 100644 manual/source/classes/contributed_definitions/icme-structure.rst delete mode 100644 manual/source/classes/contributed_definitions/sample-prep-structure.rst delete mode 100644 manual/source/classes/contributed_definitions/sts-structure.rst diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 37e76991e..000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1104 +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`. If this is not defined, p is the number of - ions included in the reconstructed volume if the application definition is used - to store results of an already reconstructed datasets. - - - - - Number of ions spatially filtered from results of the hit_finding algorithm - from which an instance of a reconstructed volume has been generated. - These ions get new identifier assigned in the process (the so-called - evaporation_identifier). This identifier must not be confused with - the pulse_identifier. - - - - - Application definition for atom probe and field ion microscopy experiments. - - - - - - - - - - - The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) - which was used to generate this NeXus file instance. - - - - - A collection of all programs and libraries which are considered relevant - to understand with which software tools this NeXus file instance was - generated. Ideally, to enable a binary recreation from the input data. - - Examples include the name and version of the libraries used to write the - instance. Ideally, the software which writes these NXprogram instances - also includes the version of the set of NeXus classes i.e. the specific - set of base classes, application definitions, and contributed definitions - with which the here described concepts can be resolved. - - For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ - which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ - research data management system, it makes sense to store e.g. the GitHub - repository commit and respective submodule references used. - - - - - - - - - - - - - - - - The identifier whereby the experiment is referred to in the control software. - This is neither the specimen_name nor the experiment_identifier. For - Local Electrode Atom Probe (LEAP) instruments, it is recommended to use the - run_number from the proprietary software IVAS/APSuite of AMETEK/Cameca. - For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, - or the instruments at GPM in Rouen, use the identifier which matches - best conceptually to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case (provided these - RHIT or HITS files respectively are stored alongside a data artifact). - With NXapm the RHIT or HITS can be stored as via the NXserialized group - in the hit_finding algorithm section. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. Such interrupted runs - should be stored as individual :ref:`NXentry` instances in one NeXus file. - - - - - Either an identifier or an alias that is human-friendly so that scientists find that experiment again. - For experiments usually this is the run_number but for simulation typically no run_numbers are issued. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize the description of their experiment - by using respective groups and fields and base classes instead of writing prose - into this field. - - The reason is that such free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn in how far the - current base classes need extension based on user feedback. - - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the atom probe session started. If the exact duration of - the measurement is not relevant start_time only should be used. - - Often though it is useful to specify both start_time and end_time to - capture more detailed bookkeeping of the experiment. The user should - be aware that even with having both dates specified, it may not be - possible to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. For this - purpose the :ref:`NXevent_data_apm` instance should be used. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the atom probe session ended. - - - - - - - - - - - - - - What type of atom probe experiment is performed? This field is meant to - inform research data management systems to allow filtering: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed such. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - few experiments of this type have been performed as this can be detrimental - to LEAP systems (see `S. Katnagallu et al. <https://doi.org/10.1017/S1431927621012381>`_). - * other should be used in combination with the user specifying details - in the experiment_documentation field. - - If NXapm is used for storing details about a simulation use other for now. - - - - - - - - - - - - - - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about knowledge they have gained about the sample. - There are cases where the specimen is machined further or exposed to - external stimuli during the experiment. In this case, these details should - not be stored under sample but suggestions should be made - how this application definition can be improved. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored. For this specific application definitions/schemas can be - used which are then arranged and documented with a description of the - workflow so that actionable graphs become instantiatable. - - - - A qualifier whether the sample is a real one - or a virtual one (in a computer simulation). - - - - - - - - - Given name/alias for the sample. - - - - - - - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size. - - In atom probe it is possible that the specimen may contain a few - crystals only. In this case the grain_diameter is not a reliable - descriptor. Reporting a grain size may be useful though as it allows - judging if specific features are expected to be found in the - detector hit map. - - - - - Magnitude of the standard deviation of the grain_diameter. - - - - - - The temperature of the last heat treatment step before quenching. - Knowledge about this value can give an idea how the sample - was heat treated. However, if a documentation of the annealing - treatment as a function of time is available one should better - rely on this information and have it stored alongside the NeXus file. - - - - - Magnitude of the standard deviation of the heat_treatment_temperature. - - - - - Rate of the last quenching step. Knowledge about this value can give - an idea how the sample was heat treated. However, there are many - situations where one can imagine that the scalar value for just the - quenching rate is insufficient. - - An example is when the sample was left in the furnace after the - furnace was switched off. In this case the sample cools down with - a specific rate of how this furnace cools down in the lab. - Processes which in practice are often not documented. - - This can be problematic though because when the furnace door was left open - or the ambient temperature in the lab changed, i.e. for a series of - experiments where one is conducted on a hot summer day and the next - during winter this can have an effect on the evolution of the microstructure. - There are many cases where this has been reported to be an QA issue in industry, - e.g. think about aging 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 which 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.-% are both - fractional quantities. - - - - - - - - - - Human-readable name of the element (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). - - - - - - - - - A qualifier whether the specimen is a real one or a virtual one. - - - - - - - - - Given name an alias. Better use identifier and parent_identifier instead. - A single NXentry should be used only for the characterization of a single specimen. - - - - - - - - - - Identifier of the sample from which the specimen was cut or the string - n/a. The purpose of this field is to support functionalities for - tracking sample provenance via a research data management system. - - - - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Ideally, this - matches the last timestamp that is mentioned in the digital resource - pointed to by 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. - - - - - List of comma-separated elements from the periodic table that are - contained in the specimen. If the specimen substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer research data management systems an - opportunity to parse the relevant elements without having to interpret - these from the resources pointed to by parent_identifier or walk through - eventually deeply nested groups in data instances. - - - - - Discouraged free-text field. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - Report if the specimen is amorphous. - - - - - Ideally measured otherwise best elaborated guess of the initial radius of the - specimen. - - - - - Ideally measured otherwise best elaborated guess of the (initial) shank angle. - This is a measure of the specimen taper. Define it in such a way that the base of the specimen - is modelled as a conical frustrum so that the shank angle is the (shortest) angle between - the specimen space z-axis and a vector on the lateral surface of the cone. - - - - - - - Set to hold different coordinate systems conventions. - Inspect the description of the :ref:`NXcoordinate_system_set` - and :ref:`NXcoordinate_system` base classes how to define - coordinate systems in NeXus. Specific details for application - in atom probe microscopy follow. - - In this research field scientists usually distinguish 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. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation identifier interval. Typically, the set of - ion evaporation sequence 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. - - To avoid these ambiguities, instances of :ref:`NXtransformations` should - be used. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The wavelength of the radiation emitted by the source. - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A region-of-interest analyzed either during or after the session for which - specific processed data of the measured or simulated data are available. - - - - - - SEM or TEM image of the initial specimen i.e. - ideally taken prior to the data acquisition. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Integer used to name the first pulse to know if there is an - offset of the evaporation_identifier 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. - - - - - (Molecular) ion identifier which resolves the sequence in which - the ions were evaporated but taking into account that a hit_finding - and spatial_filtering was applied. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - For LEAP and IVAS/APSuite-based analyses root file which stores - the settings whereby an RHIT/HITS file can be used to regenerate the - reconstruction that is here referred to. - - The respective RHIT/HITS file should ideally be specified in the serialized - group of the hit_finding section of this application definition. - - - - - - - - - For LEAP and IVAS/APSuite-based analyses the resulting typically - file with the reconstructed positions and (calibrated) mass-to-charge - state ratio values. - - For other data collection/analysis software the data artifact which comes - closest conceptually to AMETEK/Cameca's typical file formats. - - These are typically exported as a POS, ePOS, APT, ATO, ENV, or HDF5 file, - which should be stored alongside this record in the research data - management system. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The respective ranging definitions file RNG/RRNG/ENV/HDF5. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Out-of-sync) background levels in ppm/ns - reported by e.g. IVAS/APSuite for LEAP systems. - - - - - MRP, mass-resolving power, `D. Larson et al. - <https://doi.org/10.1007/978-1-4614-8721-0>`_ (p282, Eqs. D.7 and D.8). - - - - - MRP, at which mrp_value was specified. - - - - - - - - - - - - - - - - - Category for the peak offering a qualitative statement of the location of the peak - in light of limited mass-resolving power that is relevant for - composition quantification. See `D. Larson et al. (p172) <https://doi.org/10.1007/978-1-4614-8721-0>`_ - for examples of each category: - - * 0, well-separated, :math:`^{10}B^{+}`, :math:`^{28}Si^{2+}` - * 1, close, but can be sufficiently separated for quantification in a LEAP system, :math:`^{94}Mo^{3+}`, :math:`^{63}Cu^{2+}` - * 2, closely overlapping, demands better than LEAP4000X MRP can provide :math:`^{14}N^{+}`, :math:`^{28}Si^{2+}` at different charge states - * 3, overlapped exactly due to multi-charge molecular species, :math:`^{16}{O_{2}}^{2+}`, :math:`^{16}O^{+}` - * 4, overlapped, same charge state, cannot as of 2013 be discriminated with a LEAP4000X, :math:`^{14}{N_{2}}^{+}`, :math:`^{28}Si^{+}` - * 5, overlapped, same charge state, any expectation of resolvability, :math:`^{54}Cr^{2+}`, :math:`^{54}Fe^{2+}` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/applications/NXarpes.nxdl.xml b/applications/NXarpes.nxdl.xml index 9905347b5..f296bb477 100644 --- a/applications/NXarpes.nxdl.xml +++ b/applications/NXarpes.nxdl.xml @@ -30,12 +30,7 @@ This is an application definition for angular resolved photo electron spectroscopy. - It has been drawn up with hemispherical electron analysers in mind. - - This definition is a legacy support for older NXarpes experiments. - There is, however, a newer definition to collect data & metadata - for general photoemission experiments, called :ref:`NXmpes`, - as well as a specialization for ARPES experiments, called :ref:`NXmpes_arpes`." + It has been drawn up with hemispherical electron analysers in mind. @@ -136,4 +131,4 @@ - \ No newline at end of file + diff --git a/applications/NXellipsometry.nxdl.xml b/applications/NXellipsometry.nxdl.xml deleted file mode 100644 index 5769036af..000000000 --- a/applications/NXellipsometry.nxdl.xml +++ /dev/null @@ -1,422 +0,0 @@ - - - - - - - - Variables used throughout the document, e.g. dimensions or parameters. - - - - Length of the spectrum array (e.g. wavelength or energy) of the measured - data. - - - - - Number of measurements (1st dimension of measured_data array). This is - equal to the number of parameters scanned. For example, if the experiment - was performed at three different temperatures and two different pressures - N_measurements = 2*3 = 6. - - - - - Number of detection angles of the beam reflected or scattered off the - sample. - - - - - Number of angles of incidence of the incident beam. - - - - - This is the application definition describing ellipsometry experiments. - - Such experiments may be as simple as identifying how a reflected - beam of light with a single wavelength changes its polarization state, - to a variable angle spectroscopic ellipsometry experiment. - - The application definition specifies optical spectroscopy (NXopt), by extending - the terms and setting specific requirements. - - Information on ellipsometry is provided, e.g. in: - - * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, - John Wiley & Sons, 2007. - * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, - North-Holland Publishing Company, 1977. - * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, - William Andrew, 2005. - - Open access sources: - - * https://www.angstromadvanced.com/resource.asp - * https://pypolar.readthedocs.io/en/latest/ - - Review articles: - - * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", - J. Phys. D: Appl. Phys. 32, R45 (1999), - https://doi.org/10.1088/0022-3727/32/9/201 - * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", - Thin Solid Films 571, 334-344 (2014), - https://doi.org/10.1016/j.tsf.2014.03.056 - * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", - Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, - (3 October 1997), - https://doi.org/10.1117/12.283870 - * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", - Thin Solid Films 233, 96-111 (1993), - https://doi.org/10.1016/0040-6090(93)90069-2 - * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", - Adv. Opt. Techn., (2022), - https://doi.org/10.1515/aot-2022-0016 - - - - - An application definition for ellipsometry. - - - - Version number to identify which definition of this application - definition was used for this entry/data. - - - - - URL where to find further material (documentation, examples) relevant - to the application definition. - - - - - - - - - - Specify the type of the optical experiment. - - You may specify fundamental characteristics or properties in the experimental sub-type. - - - - - - - - Specify the type of ellipsometry. - - - - - - - - - - - - - - If the ellipsometry_experiment_type is `other`, a name should be specified here. - - - - - Properties of the ellipsometry equipment. - - - - What type of ellipsometry was used? See Fujiwara Table 4.2. - - - - - - - - - - - - - - - - - - - - If the ellipsometer_type is `other`, a specific ellipsometry_type" should be - added here. - - - - - Define which element rotates, e.g. polarizer or analyzer. - - - - - - - - - - - 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 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. - - - - - - - - Was the backside of the sample roughened? Relevant for infrared - ellipsometry. - - - - - - - Measured data, data errors, and varied parameters. This may be used to describe - indirectly derived data or data transformed between different descriptions, - such as: - Raw Data --> Psi - Delta Psi, Delta --> N,C,S - Mueller matrix --> N,C,S - Mueller matrix --> Psi, Delta - etc. - - Other types of data, such as temperature or sample location, may be saved - in a generic (NXdata) concept from NXopt, or better directly in the - location of the sample positioner or temperature sensor. - - - - An identifier to correlate data to the experimental conditions, - if several were used in this measurement; typically an index of 0-N. - - - - - Select which type of data was recorded, for example intensity, - reflectivity, transmittance, Psi and Delta etc. - It is possible to have multiple selections. The enumeration list - depends on the type of experiment and may differ for different - application definitions. - - - - - - - - - - - - - - - - Spectral values (e.g. wavelength or energy) used for the measurement. - An array of 1 or more elements. Length defines N_spectrum. Replace - 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. - - - - - - - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - - - - - - Resulting data from the measurement, described by 'data_type'. - - The first dimension is defined by the number of measurements taken, - (N_measurements). The instructions on how to order the values - contained in the parameter vectors given in the doc string of - INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, - define the N_measurements parameter sets. For example, if the - experiment was performed at three different temperatures - (T1, T2, T3), two different pressures (p1, p2) and two different - angles of incidence (a1, a2), the first measurement was taken at the - parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. - - - - - - - - - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - - - - - - Specified uncertainties (errors) of the data described by 'data_type' - and provided in 'measured_data'. - - - - - - - - - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - - - - - - List of links to the values of the sensors. Add a link for each - varied parameter (i.e. for each sensor). - - - - - - - - Link to the NeXus file which describes the reference data if a - reference measurement was performed. Ideally, the reference - measurement was performed using the same conditions as the actual - measurement and should be as close in time to the actual measurement - as possible. - - - - - - Commercial or otherwise defined given name of the program that was - used to generate the result file(s) with measured data and/or - metadata (in most cases, this is the same as INSTRUMENT/software). - If home written, one can provide the actual steps in the NOTE - subfield here. - - - - - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - - - - - Website of the software. - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index 9ab06b6ba..000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,1663 +0,0 @@ - - - - - - Application definition for normalized representation of electron microscopy research. - - This application definition is a comprehensive example for a general description - with which to normalize specific pieces of information and data collected within - electron microscopy research. - - NXem is designed to be used for documenting experiments or computer simulations in which - controlled electron beams are used for studying electron-beam matter interaction to explore - physical mechanisms and phenomena, or to characterize materials with an electron microscope. - - - - - - - - - - - - The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) - which was used to generate this NeXus file instance. - - - - A collection of all programs and libraries that are considered as relevant - to understand with which software tools this NeXus file instance was - generated. Ideally, to enable a binary recreation from the input data. - - Examples include the name and version of the libraries used to write the - instance. Ideally, the software which writes these NXprogram instances - also includes the version of the set of NeXus classes i.e. the specific - set of base classes, application definitions, and contributed definitions - with which the here described concepts can be resolved. - - For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ - which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ - research data management system, it makes sense to store e.g. the GitHub - repository commit and respective submodule references used. - - - - - - - - - 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. - - - - - - - - Alias which scientists can easier identify this experiment by. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize the description of their experiment - by using respective groups and fields and base classes instead of writing prose - into the field. The reason is that such free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn in how far the - current base classes need extension based on user feedback. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant use this start_time field. - - Often though it is useful to specify a time interval via setting both a start_time - and an end_time because this enables software tools and users to collect a - more detailed bookkeeping of the experiment. - - Users should be aware though that even 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 to use the - start_time and end_time together. - - - - - - Possibility to store a collection of serialized resources associated with the - experiment. - - An example how to use this set could be to document from which files, which have been - e.g. generated by software of technology partners, the information in an instance of - NXem was filled with during parsing or transcoding between different formats. - - - - - - - - - - Information about persons who performed or were involved in the microscope - session or simulation run. - - This can be the principle investigator who performed this experiment or the student who performed simulations. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname. - - - - - Name of the affiliation at the point in time when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address at the point in time when the experiment was performed. - - Writing the most permanently used email is recommended. - - - - - Telephone number at the point in time when the experiment was performed. - - - - - User role at the point in time when the experiment was performed. - - Examples are technician operating the microscope, student, postdoc, - principle investigator, or guest. - - - - - Identifier offered by a service to report the user other than by using its name. - - Examples could be an ORCID or social media account of the user. - - - - - - - - - A physical entity which contains material intended to be investigated. - Sample and specimen are treated as de facto synonyms. Samples can be real or virtual ones. - - This concept is related to term `Specimen`_ of the EMglossary standard. - - .. _Specimen: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 - - - - Qualifier whether the sample is a real or a virtual one. - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes the sample from all others - and especially the predecessor/origin from where that sample was cut. The terms sample - and specimen are here considered as exact synonyms. - - This field must not be used for an alias! Instead, use name. - - In cases where multiple specimens were loaded into the microscope, the identifier has to resolve - the specific sample, whose results are stored by this :ref:`NXentry` instance because a single - NXentry should be used for the characterization of a single specimen. - - Details about the specimen preparation should be stored in resources referring to 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 in a research data management system. - - - - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known timestamp when - the measured specimen surface was actively prepared. Ideally, this matches - the last timestamp that is mentioned in the digital resource pointed to by - parent_identifier. - - Knowing when the specimen was exposed to e.g. specific atmosphere is especially - required for environmentally sensitive material such as specimen charged with hydrogen - or experiments including tracers that have a short halflife. 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 the responsibility of the - research data management system not of a NeXus file. - - - - - An alias used to refer to the specimen to please readability for humans. - - - - - List of comma-separated elements from the periodic table that are contained in the sample. - If the sample substance has multiple components, all elements from each component - must be included in atom_types. - - The purpose of the field is to offer research data management systems an opportunity - to parse the relevant elements without having to interpret these from the resources - pointed to by parent_identifier or walk through eventually deeply nested groups in - individual data instances. - - - - - (Measured) sample thickness. - - The information is recorded to qualify if the beam used was likely - able to shine through the specimen. For scanning electron microscopy, - in many cases the specimen is typically thicker than what is - illuminatable by the electron beam. - - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. - - For multi-layered specimens this field should only be used to describe - the density of the excited volume. For scanning electron microscopy - the usage of this field is discouraged and instead an instance of 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. - - - - - - Set to hold different coordinate systems conventions. - - Inspect the description of the :ref:`NXcoordinate_system_set` and :ref:`NXcoordinate_system` base classes - how to define coordinate systems in NeXus. - - - - - - - - - - - - - - Location of the origin of the processing_reference_frame. - - It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. - Edges are interpreted by inspecting the direction of their outer unit normals - (which point either parallel or antiparallel) along respective base vector direction - of the reference frame. - - If any of these assumptions is not met, the user is required to explicitly state this. - - - - - - - - - - - - - - - - Direction of the positively pointing x-axis base vector of the - processing_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing y-axis base vector of the - processing_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing z-axis base vector of the - processing_reference_frame. - - - - - - - - - - - - - - - - Reference to the specifically named :ref:`NXsample` instance(s) for - which these conventions apply (e.g. /entry1/sample1). - - - - - - - - Location of the origin of the sample_reference_frame. - - It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. - Edges are interpreted by inspecting the direction of their outer unit normals - (which point either parallel or antiparallel) along respective base vector direction - of the reference frame. - - If any of these assumptions is not met, the user is required to explicitly state this. - - - - - - - - - - - - - - - - Direction of the positively pointing x-axis base vector of the - sample_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing y-axis base vector of the - sample_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing z-axis base vector of the - sample_reference_frame. - - - - - - - - - - - - - - - - Reference to the specifically named :ref:`NXdetector` instance for - which these conventions apply (e.g. /entry1/instrument/detector1). - - - - - - - - Location of the origin of the detector_reference_frame. - - If the regions-of-interest forms a rectangle or cuboid, it is assumed that edges are interpreted - by inspecting the direction of their outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - - If any of these assumptions is not met, the user is required to explicitly state this. - - - - - - - - - - - - - - - - Direction of the positively pointing x-axis base vector of the - detector_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing y-axis base vector of the - detector_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing z-axis base vector of the - detector_reference_frame. - - - - - - - - - - - - - - - - - - - - - - - - - - Details about the control program used for operating the microscope. - - - - - - - - - - - - - - - This concept is related to term `Source`_ of the EMglossary standard. - - .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 - - - - - - - - - - - - - - - - - - - - - - - - - - - - Device for improving energy resolution or reducing chromatic aberration. - - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector - like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ - - - - - Qualitative type of the component. - - - - - - - - - - - - - - - - - - - - - - - - - - - Device reshaping an ellipse-shaped electron beam to a circular one. - - * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ - * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ - - Stigmator is an exact synonym. - - - - - - - - - - Electron biprism as it is used e.g. for electron holography. - - - - - - - - - - - Device that causes a change in the phase of an electron wave. - - * `M. Malac et al. <https://doi.org/10.1093/jmicro/dfaa070>`_ - * `R. R. Schröder et al. <https://www.lem.kit.edu/152.php>`_ - - - - Qualitative type - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Device for improving energy resolution or reducing chromatic aberration. - - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector - like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ - - - - Qualitative type of the component. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This concept is related to term `Source`_ of the EMglossary standard. - - .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 - - - - The potential difference between anode and cathode. - - This concept is related to term `Acceleration Voltage`_ of the EMglossary standard. - - .. _Acceleration Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000004 - - - - - Voltage which is utilised to create an electric field that draws particles from - the source. - - This concept is related to term `Extraction Voltage`_ of the EMglossary standard. - - .. _Extraction Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 - - - - - Electrical current which is released from the source. - - This concept is related to term `Emission Current`_ of the EMglossary standard. - - .. _Emission Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 - - - - - Electrical current which flows through the source. - - This concept is related to term `Filament Current`_ of the EMglossary standard. - - .. _Filament Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 - - - - - - - - - - Relevant value from the control software. - - This is not always just the diameter of the aperture (not even in the case) - of a circular aperture. Usually, it is a value that is set in the control - software whereby a specific configuration of an aperture is selected by the - software. - - The control software of commercial microscope typically offers the user - access at a high abstraction level because of which many details about - the actual settings of the electrical components are typically unknown. - - However, if more details are known or should be documented one should - use the description field for this. - - - - - - Device to improve energy resolution or chromatic aberration. - - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector - like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ - - - - - Was the corrector used? - - - - - - Energy dispersion in e.g. µm/eV. - - - - - Corresponding voltage for that energy dispersion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Device reshaping an ellipse-shaped electron beam to a circular one. - - * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ - * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ - - Stigmator is an exact synonym. - - - - Was the corrector used? - - - - - Descriptor for the correction strength along the first direction when exact technical details - are unknown or not directly controllable as the control software of the microscope does not - enable or was not configured to display these values (for end users). - - - - - Descriptor for the correction strength along the second direction when exact technical details - are unknown or not directly controllable as the control software of the microscope does not - enable or was not configured to display these values (for end users). - - - - - - - - - - This concept is related to term `Electron Beam`_ of the EMglossary standard. - - .. _Electron Beam: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 - - - - - - - - - - - - - - - Relevant value from the control software. - - This is not always just the diameter of the aperture (not even in the case) - of a circular aperture. Usually, it is a value that is set in the control - software whereby a specific configuration of an aperture is selected by the - software. - - The control software of commercial microscope typically offers the user - access at a high abstraction level because of which many details about - the actual settings of the electrical components are typically unknown. - - However, if more details are known or should be documented one should - use the description field for this. - - - - - - - - - - - - - - - - - - - - - - - Nominal current of the heater. - - - - - Nominal voltage of the heater. - - - - - Nominal power of the heater. - - - - - - - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data are available. - - This concept is related to term `Region Of Interest`_ of the EMglossary standard. - - .. _Region Of Interest: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/applications/NXmpes.nxdl.xml b/applications/NXmpes.nxdl.xml deleted file mode 100644 index d2d60e2ea..000000000 --- a/applications/NXmpes.nxdl.xml +++ /dev/null @@ -1,918 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of data points in the transmission function. - - - - - This is the most general application definition for - photoemission experiments. - - Groups and fields are named according to the - `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 - - - - - - - - - - - - Datetime of the start of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - - - - - Datetime of the end of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - - - - - Name of the experimental method. - - If applicable, this name should match the terms given by `Clause 11`_ of - the `ISO 18115-1:2023`_ specification. - - Examples include: - * X-ray photoelectron spectroscopy (XPS) - * angle-resolved X-ray photoelectron spectroscopy (ARXPS) - * ultraviolet photoelectron spectroscopy (UPS) - * angle-resolved photoelectron spectroscopy (ARPES) - * hard X-ray photoemission spectroscopy (HAXPES) - * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * photoelectron emission microscopy (PEEM) - * electron spectroscopy for chemical analysis (ESCA) - * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) - * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) - * momentum microscopy - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - - - - - Description of one or more coordinate systems that are specific to the setup - and the measurement geometry. - - - - - 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 time when the experiment was - performed. - - - - - - Description of the photoemission spectrometer and its individual parts. - - This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. - - .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - - - - Overall energy resolution of the photoemission instrument. - - - - - - - - - - Minimum distinguishable energy separation in the energy spectra. - - This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. - - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - - - - - Ratio of the energy resolution of the photoemission spectrometer at a specified energy - value to that energy value. - - This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. - - .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - - - - - - - - - - - A source used to generate a beam. 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 - or similar. - - Note that the uppercase notation in sourceTYPE means that multiple sources can - be provided. The uppercase part can be substituted with any string that consists - of alphanumeric characters, including both uppercase and lowercase letters from A to Z - and numerical digits from 0 to 9. For example, in pump-probe experiments, it is possible - to have both a `source_probe` and a `source_pump`. - - - - - - - - - - - - - - - - - - - - Specification of type, may also go to name. - - - - - - - - - - - - A reference to a beam emitted by this source. - Should be named with the same appendix, e.g., - for `source_probe` it should refer to `beam_probe`. - - Example: - * /entry/instrument/source_probe = /entry/instrument/beam_probe - - - - - - Properties of the photon beam at a given location. - Should be named with the same appendix as sourceTYPE, e.g., - for `source_probe` it should refer to `beam_probe`. - - - - Distance between the point where the current NXbeam instance is evaluating - the beam properties and the point where the beam interacts with the sample. - For photoemission, the latter is the point where the the centre of the beam - touches the sample surface. - - - - - - - - - The source that emitted this beam. - Should be named with the same appendix, e.g., - for `beam_probe` it should refer to `source_probe`. - This should be specified if an associated source exists. - - Example: - * /entry/instrument/beam_probe = /entry/instrument/source_probe - - - - - - - - - - - - - - - - - - - - - - - - - - - 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 iris inserted in the column. - - The iris is an aperture in the lens with a variable diameter which can reduce the number of - electrons entering the analyzer. - - To add additional or other slits use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - - - - Either `pass_energy` or `drift_energy` must be supplied. `pass_energy` should be used when working - with hemispherical analysers. - - - - - Either `pass_energy` or `drift_energy` must be supplied. `drift_energy` should be used if a TOF is used in the - energy dispersive part of the electron analyzer. - - - - - - 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. - - - - - - - - - - - - - - - - - - Contains the raw data collected by the detector before calibration. - The data which is considered raw might change from experiment to experiment - due to hardware pre-processing of the data. - This group ideally collects the data with the lowest level of processing - possible. - - Fields should be named according to the following convention: - - - **pixel_x**: Detector pixel in x direction. - - **pixel_y**: Detector pixel in y direction. - - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). - - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). - Unit category: NX_ANGLE - - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_ANGLE - - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) - Unit category: NX_LENGTH - - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_LENGTH - - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - - **polarization_angle**: Linear polarization angle of the incoming or - outgoing beam. - Unit category: NX_ANGLE (° or rad) - - **ellipticity**: Ellipticity of the incoming or outgoing beam. - Unit category: NX_ANGLE (° or rad) - - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT - - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. - - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. - - Note that this list is a glossary with explicitly named axis names, which is only intended to cover the most - common measurement axes and is therefore not complete. It is possible to add axes with other names at any time. - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Device to measure the gas pressure in the instrument. - - - - - - - - - - - In case of a single or averaged gas pressure measurement, this is the scalar gas pressure. - It can also be an 1D array of measured pressures (without time stamps). - - - - - - In the case of an experiment in which the gas pressure changes and is recorded, - this is an array of length m of gas pressures. - - - - - - - Device to bring low-energy electrons to the sample for charge neutralization - - - - - - - - - - - In case of a fixed or averaged electron current, this is the scalar current. - It can also be an 1D array of output current (without time stamps). - - - - - - In the case of an experiment in which the electron current is changed and - recorded with time stamps, this is an array of length m of current setpoints. - - - - - - - A set of activities that occurred to the instrument prior to/during the photoemission - experiment, including any activities performed on the individual instrument parts. - This group can be used to describe the preparation of the instrument prior to the - experiment, e.g. the cleaning procedure for a spin filter crystal. - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - The appropriate axis calibrations for a given experiment should be described using - one or more of the following NXcalibrations. The individual calibrations for a given - `AXISNAME` in `data` should be called `AXISNAME_calibration`. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Kinetic energy values - - - - - - - - Relative transmission efficiency for the given kinetic energies - - - - - - - - - - - - - - For samples containing a single pure substance. For mixtures use the - NXsample_component_set and NXsample_component group in NXsample instead. - - - - The chemical formula of the sample (using CIF conventions). - - - - - - 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`. - - - - - - - - - - - - - - A set of activities that occurred to the sample prior to/during photoemission - experiment. - - - - Details about the sample preparation for the photoemission experiment (e.g. UHV cleaving, - in-situ growth, sputtering/annealing, etc.). - - - - - - Details about the method of sample preparation before the photoemission - experiment. - - - - - - - Sample temperature (either controlled or just measured) and actuators/sensors - controlling/measuring it. - - - - Temperature sensor measuring the sample temperature. - - In most cases, this can be a link to /entry/instrument/manipulator/temperature_sensor - if a manipulator is present in the instrument. - - - - - Device to heat the sample. - - In most cases, this can be a link to /entry/instrument/manipulator/sample_heater - if a manipulator is present in the instrument. - - - - - Cryostat for cooling the sample. - - In most cases, this can be a link to /entry/instrument/manipulator/cryostat - if a manipulator is present in the instrument. - - - - - This is to be used if there is no actuator/sensor that controls/measures - the temperature. - - An example would be a room temperature experiment where the temperature is - not actively measured, but rather estimated. - - Note that this method for recording the temperature is not advised, but using - NXsensor and NXactuator is strongly recommended instead. - - - - - - Gas pressure surrounding the sample and actuators/sensors controlling/measuring - it. - - - - Gauge measuring the gas pressure. - - In most cases, this can be a link to /entry/instrument/pressure_gauge or to another - NXsensor measuring gas pressure (typically, the gauge in closest proximity to the - sample) if such a pressure gauge is present in the instrument. - - - - - This is to be used if there is no actuator/sensor that controls/measures - the gas pressure around the sample. An example would be a UHV experiment where the - gas pressure is not monitored. - - Note that this method for recording the gas pressure is not advised, but using - NXsensor and NXactuator is strongly recommended instead. - - - - - - Bias of the sample with respect to analyser ground and actuators/sensors - controlling/measuring it. - - This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. - - .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 - - - - Sensor measuring the applied voltage. - - In most cases, this can be a link to /entry/instrument/manipulator/sample_bias_voltmeter - if a manipulator is present in the instrument. - - - - - Actuator applying a voltage to sample and sample holder. - - In most cases, this can be a link to /entry/instrument/manipulator/sample_bias_potentiostat - if a manipulator is present in the instrument. - - - - - This is to be used if there is no actuator/sensor that controls/measures - the bias. - - Note that this method for recording the bias is not advised, but using - NXsensor and NXactuator is strongly recommended instead. - - - - - - Drain current of the sample and sample holder. - - - - Amperemeter measuring the drain current of the sample and sample holder. - - In most cases, this can be a link to /entry/instrument/manipulator/drain_current_amperemeter - if a manipulator is present in the instrument. - - - - - This is to be used if there is no actuator/sensor that controls/measures - the drain current. - - Note that this method for recording the drain current is not advised, but using - NXsensor and NXactuator is strongly recommended instead. - - - - - - Current of low-energy electrons to the sample (for charge neutralization) and - actuators/sensors controlling/measuring it. - - - - Flood gun creating a current of low-energy electrons. - - In most cases this can be a link to /entry/instrument/flood_gun - if a flood_gun is present in the instrument. - - - - This is to be used if there is no actuator/sensor that controls/measures - the drain_current. - - Note that this method for recording the flood gun current is not advised, but using - NXsensor and NXactuator is strongly recommended instead. - - - - - - - - The default NXdata group containing a view on the measured data. - This NXdata group contains a collection of the main relevant fields (axes). - If you want to provide additional views on your data, you can additionally use - the generic NXdata group of NXentry. - - In NXmpes, it is recommended to provide an energy axis. - - Fields should be named according to the following convention: - - - **energy**: Calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). - - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). - Unit category: NX_ANGLE - - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_ANGLE - - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) - Unit category: NX_LENGTH - - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_LENGTH - - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - - **polarization_angle**: Linear polarization angle of the incoming or - outgoing beam. This could be a link to - /entry/instrument/beam/incident_polarization_angle or - /entry/instrument/beam/final_polarization_angle if they exist. - Unit category: NX_ANGLE (° or rad) - - **ellipticity**: Ellipticity of the incoming or outgoing beam. - Could be a link to /entry/instrument/beam/incident_ellipticity or - /entry/instrument/beam/final_ellipticity if they exist. - Unit category: NX_ANGLE (° or rad) - - Note that this list is a glossary with explicitly named axis names, which is only intended to cover the most - common measurement axes and is therefore not complete. It is possible to add axes with other names at any time. - - - - - - - - - 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. - - - - - Calibrated energy axis. - - Could be linked from the respective '@reference' field. - - - - The energy can be either stored as kinetic or as binding energy. - - - - - Calibrated kinetic energy axis. - - In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` - (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are - provided as :math:`E-E_F`. - - This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. - - .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - - - - - Calibrated binding energy axis. - - This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. - - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - - - The energy can be dispersed according to different strategies. ``@reference`` points to - the path of a field defining the calibrated axis which the ``energy`` axis refers. - - For example: - @reference: 'entry/process/energy_calibration/calibrated_axis' - - - - - - - diff --git a/applications/NXmpes_arpes.nxdl.xml b/applications/NXmpes_arpes.nxdl.xml deleted file mode 100644 index d18d0056c..000000000 --- a/applications/NXmpes_arpes.nxdl.xml +++ /dev/null @@ -1,417 +0,0 @@ - - - - - - - This is an general application definition for angle-resolved multidimensional - photoelectron spectroscopy. - - - - - - - - - - - - - Link to transformations defining an APRES base coordinate system, - which is defined such that the positive z-axis points towards the analyzer entry, - and the x-axis lies within the beam/analyzer plane. - - - - - Set of transformations, describing the orientation of the ARPES coordinate system - with respect to the beam coordinate system (.). - - - - - - - - Overall angular resolution along the Nth angular axis. Create one such entry per relevant angular axis, - corresponding to the angular axes in NXdata. - For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, - and angular1_resolution to the one perpendicular to it. - - - - - - - - - - - - - Analyzer angular resolution along the Nth angular axis. - Create one such entry per relevant angular axis, corresponding to the angular axes in NXdata. - For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, - and angular1_resolution to the one perpendicular to it. - - - - - - - - - - - - Reference to the last transformation describing the orientation of the analyzer relative to the beam, - e.g. transformations/analyzer_elevation. - - - - - Set of transformations, describing the relative orientation of the analyzer - with respect to the beam coordinate system (.). - - - - Rotation about the analyzer lens axis. - Its zero reference is defined such that the angular0 axis is - increasing towards the positive y axis (analyzer slit vertical). - - - - - - - - - - - - - - Path to a transformation that places the analyzer origin system into the - arpes_geometry coordinate system. - - - - - - Elevation of the effective analyzer acceptance area, e.g. realized by - deflectors, or as one angle in a TOF detector. If a resolved angle, place the - calibrated axis coordinates here. - - - - - - - - - - - - - - - - - - - - In-plane analyzer coordinate along a dispersive direction, - e.g. along an analyzer slit. If a resolved angle, place the calibrated coordinates here. - - - - - - - - - - - - - - - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Reference to the end of the transformation chain, - orienting the sample surface within the arpes_geometry coordinate system - (sample_azimuth or anything depending on it). - - - - - Set of transformations, describing the relative orientation of the sample - with respect to the arpes_geometry coordinate system. - - - - Rotation about the y axis (typically the long manipulator axis). - - - - - - - - - - - - - - Path to a transformation that places the sample surface - into the origin of the arpes_geometry coordinate system. - - - - - - Offset of polar rotation. - - - - - - - - - - - - - - - - - - - - Rotation about the x axis (typically a manipulator tilt). - - - - - - - - - - - - - - - - - - - - Offset of tilt rotation. - - - - - - - - - - - - - - - - - - - - Rotation about the z axis (azimuthal rotation within the sample plane). - - - - - - - - - - - - - - - - - - - - Offset of azimuthal rotation. - - - - - - - - - - - - - - - - - - - - - - - There is an object named data that contains the signal. - - - - - - - - There are three dimensions, one energy and two angular coordinates. Any coordinates that do not move, - are represented by one point. - - - - - - - - - - - Trace of the energy axis. Could be linked from the respective ``@reference`` - field. - - - - Points to the path of a field defining the calibrated axis which the energy axis refers. - - For example: - @reference: '/entry/instrument/detector/sensor_y' for a 2D detector - @reference: '/entry/instrument/energydispersion/center_kinetic_energy' for a swept scan - @reference: '/entry/process/calibration/energy_calibration/calibrated_axis' for a preprocessed axis. - - - - - - Trace of the first angular axis. Could be linked from the respective - ``@reference`` field. - - - - Points to the path of a field defining the calibrated axis which the ``angular0`` axis refers. - - For example: - @reference: '/entry/sample/transformations/sample_tilt' for a manipulator angular scan - @reference: '/entry/instrument/detector/sensor_x' for a 2D detector - @reference: '/entry/instrument/collectioncolumn/deflector' for a deflector scan - @reference: '/entry/process/calibration/angular0_calibration/calibrated_axis' for a preprocessed axis. - - - - - - Trace of the second axis. Could be linked from the respective ``@reference`` - field. - - - - Points to the path of a field defining the calibrated axis which the ``angular1`` axis refers. - - For example: - @reference: '/entry/sample/transformations/sample_polar' for a manipulator angular scan - @reference: '/entry/instrument/detector/sensor_y' for a 2D detector - @reference: '/entry/instrument/collectioncolumn/deflector' for a deflector scan - @reference: '/entry/process/calibration/angular1_calibration/calibrated_axis' for a preprocessed axis. - - - - - - Represents a measure of three-dimensional photoemission counts, where - the varied axes are energy, and one or more angular coordinates. Axes traces - should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/applications/NXoptical_spectroscopy.nxdl.xml b/applications/NXoptical_spectroscopy.nxdl.xml deleted file mode 100644 index 196021345..000000000 --- a/applications/NXoptical_spectroscopy.nxdl.xml +++ /dev/null @@ -1,1218 +0,0 @@ - - - - - - - - Variables used throughout the document, e.g. dimensions or parameters. - - - - Length of the spectrum array (e.g. wavelength or energy) of the measured - data. - - - - - Number of measurements (1st dimension of measured_data array). This is - equal to the number of parameters scanned. For example, if the experiment - was performed at three different temperatures and two different pressures - N_measurements = 2*3 = 6. - - - - - A general application definition of optical spectroscopy elements, which may - be used as a template to derive specialized optical spectroscopy experiments. - - Possible specializations are ellipsometry, Raman spectroscopy, photoluminescence, - reflectivity/transmission spectroscopy. - - A general optical experiment consists of (i) a light/photon source, (ii) a sample, - (iii) a detector. - - For any free text descriptions, it is recommended to enter data in english - language, as this is the most FAIR representation. - - - - - An application definition describing a general optical experiment. - - - - Version number to identify which definition of this application - definition was used for this entry/data. - - - - - URL where to find further material (documentation, examples) relevant - to the application definition. - - - - - - - - - - Datetime of the start of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise, the local time zone is assumed per ISO8601. - - It is required to enter at least one of both measurement times, either "start_time" or "end_time". - - - - - Datetime of the end of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - - It is required to enter at least one of both measurement times, either "start_time" or "end_time". - - - - - A (globally persistent) unique identifier of the experiment. - (i) The identifier is usually defined by the facility, laboratory or - principal investigator. - (ii) The identifier enables to link experiments to e.g. proposals. - - - - - - Select the range of validity of this identier. - Local: Setup#1 at Institute building #2 in Room #3 - Global: Unique identification of with by unique location and unique - globally persistent time stamp. - - - - - - - - - - - An optional free-text description of the experiment. - - Users are strongly advised to parameterize the description of their experiment - by using respective groups and fields and base classes instead of writing prose - into this field. - - The reason is that such a free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn how far the - current base classes need extension based on user feedback. - - - - - Specify the type of the optical experiment. - - Chose other if none of these methods are suitable. You may specify - fundamental characteristics or properties in the experimental sub-type. - - For Raman spectroscopy or ellipsometry use the respective specializations - of NXoptical_spectroscopy. - - - - - - - - - - - Specify a special property or characteristic of the experiment, which specifies - the generic experiment type. - - - - - - - - - - - If "other" was selected in "experiment_type" and/or in "experiment_sub_type", - specify the experiment here with a free text name, which is knwon in the - respective community of interest. - - - - - Description of one or more coordinate systems that are specific to the - experiment. Examples are beam centered, sample-normal centered, - laboratory-system centered, sample-stage centered, crystal-symmetry centered. - - - - - This refers to the coordinate system along the beam path. The origin and - base is defined at z=0, where the incident beam hits the sample at the surface. - - - - - This is the default NeXus coordinate system (McStas), if the transformation - does not change the coordinate system at all - i.e. it is unity. - Otherwise, by this a respective transformation of the beam - reference frame to the default reference frame could be made. i.e. - exchange of x and z coordinate, rotation of respective coordinates - towards each other. - - - - - - - Link to transformations defining the sample-normal base coordinate system, - which is defined such that the positive z-axis is parallel to the sample normal, - and the x-y-plane lies inside the sample surface. - - - - - Set of transformations, describing the orientation of the sample-normal coordinate system - with respect to the beam coordinate system (.). - - - - - - - Contact information and eventually details of at persons who - performed the measurements. This can be for example the principal - investigator or student. Examples are: name, affiliation, address, telephone - number, email, role as well as identifiers such as orcid or similar. - It is recommended to add multiple users if relevant. - - Due to data privacy concerns, there is no minimum requirement. - If no user with specific name is allowed to be given, it is required to - assign at least an affiliation - - - - - Devices or elements of the optical spectroscopy setup described with its - properties and general information. - - This includes for example: - - The beam device's or instrument's model, company, serial number, construction year, etc. - - Used software or code - - Experiment descriptive parameters as reference frames, resolution, calibration - - Photon beams with their respective properties such as angles and polarization - - Various optical beam path devices, which interact, manipulate or measure optical beams - - Characteristics of the medium surrounding the sample - - "Beam devices" for a beam path description - - Stages(NXmanipulator) - - Sensors and actuators to control or measure sample or beam properties - - - - This can be used to describe properties of a photon beam. - A beam is always defined between two beam_devices, via - "previous_device" and "next_device". - - It is required to define at least one incident beam which is incident - to the sample. You may specify if this beam parameters are acutally measured - or just nominal. - If this beam is the output of a source, chose the same - name appendix as for the NXsource instance (e.g. TYPE=532nm) - - - - Select the reliability of the respective beam characteristics. Either, - the parameters are measured via another device or method or just given - nominally via the properties of a light source properties (532nm, 100mW). - - - - - - - - - - - - - The path to the device which emitted this beam (light source or frequency doubler). - - This parameter is recommended, if the previous optical element is a photon source. - In this way, the properties of the laser or light souce can be described - and associated. - The beam should be named with the same appendix as the source, e.g., - for TYPE=532nmlaser, there should be both a NXsource named - "source_532nmlaser" and a NXbeam named "beam_532nmlaser". - - Example: /entry/instrument/source_532nmlaser - - - - - - - - - - - - - - Angle of the linear polarized light, with respect to a fixed arbitrary - defined 0° position. This can be used if no definition of respective - cooridnate systems for beam and sample normal is done. If coordinate systems - are defined, refer to beam "incident_polarization". - - - - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - Type of detector, if "other" was selected in "detector_type". - - - - - Contains the raw data collected by the detector before calibration. - The data which is considered raw might change from experiment to experiment - due to hardware pre-processing of the data. - This field ideally collects the data with the lowest level of processing - possible. - - - - - - - - - - Raw data before calibration. - - - - - - Specify respective hardware which was used for the detector. For - example special electronics required for time-correlated single photon - counting (TCSPC). - - - - - - - - - - - - - - - - - - - - - - - - Specification of type, may also go to name. - - - - - - If available, name/ID/norm of the light source standard. - - - - - Details about the device information. - - - - - The path to a beam emitted by this source. - Should be named with the same appendix, e.g., - for TYPE=532nmlaser, there should as well be - a NXbeam named "beam_532nmlaser" together with this source - instance named "source_532nmlaser" - - Example: /entry/instrument/beam_532nmlaser - - - - - - - - - Defines the reference frame which is used to describe the sample orientation - with respect to the beam directions. - - A beam centered description is the default and uses 4 angles(similar to XRD): - - Omega (angle between sample surface and incident beam) - - 2Theta (angle between the transmitted beam and the detection beam) - - Chi (sample tilt angle, angle between plane#1 and the surface normal, - plane#1 = spanned by incidence beam and detection - and detection. If Chi=0°, then plane#1 is the plane of - incidence in reflection setups) - - Phi (inplane rotation of sample, rotation axis is the samples - surface normal) - - - A sample normal centered description is as well possible: - - angle of incidence (angle between incident beam and sample surface) - - angle of detection (angle between detection beam and sample surface) - - angle of incident and detection beam - - angle of in-plane sample rotation (direction along the sample's surface normal) - - An arbitrary reference frame can be defined by "reference_frames" - and used via "instrument/angle_sample_and_beam_TYPE" - - - - - - - - - Angle between sample incident beam and sample surface. - - - - - Angle between incident and detection beam - - - - - Sample tilt between sample normal, and the plane spanned by detection and - incident beam. - - - - - Inplane rotation of the sample, with rotation axis along sample normal. - - - - - Angle(s) of the incident beam vs. the normal of the bottom reflective - (substrate) surface in the sample. These two directions span the plane - of incidence. - - - - - Detection angle(s) of the beam reflected or scattered off the sample - vs. the normal of the bottom reflective (substrate) surface in the - sample if not equal to the angle(s) of incidence. - These two directions span the plane of detection. - - - - - Angle between the incident and detection beam. - If angle_of_detection + angle_of_incidence = angle_of_incident_and_detection_beam, - then the setup is a reflection setup. - If angle_of_detection + angle_of_incidence != angle_of_incident_and_detection_beam - then the setup may be a light scattering setup. - (i.e. 90° + 90° != 90°, i.e. incident and detection beam in the sample surface, but - the angle source-sample-detector is 90°) - - - - - Angle of the inplane orientation of the sample. This might be an arbitrary, - angle without specific relation to the sample symmetry, - of the angle to a specific sample property (i.e. crystallographic axis or sample - shape such as wafer flat) - - - - - Set of transformations, describing the relative orientation of different - parts of the experiment (beams or sample). You may select one of the specified - angles for incident and detection beam or sample, and then use polar and azimuthal - angles to define the direction via sperical coordinates. - This allows consistent defintion between different coordinate system. - You may refer to self defined coordinate system as well. - - - If "angle_reference_frame = beam centered", then this coordinate system is used: - McStas system (NeXus default) - (https://manual.nexusformat.org/design.html#mcstas-and-nxgeometry-system) - - i.e. the z-coordinate math:`[0,0,1]` is along the incident beam direction and - the x-coordinate math:`[1,0,0]` is in the horizontal plane. Hence, usually math:`[0,1,0]` - is vertically oriented. - - If "angle_reference_frame = sample-normal centered", then this coordinate - system is used - z - math:`[0,0,1]` along sample surface normal - x - math:`[1,0,0]` defined by sample surface projected incident beam. - y - math:`[0,1,0]` in the sample surface, orthogonal to z and x. - For this case, x may be ill defined, if the incident beam is perpendicular - to the sample surface. In this case, use the beam centered description. - - - - - - - - - - - Rotation about the y axis (polar rotation within the sample plane). - - - - - - - - - - - - - - Path to a transformation that places the sample surface - into the origin of the arpes_geometry coordinate system. - - - - - - Rotation about the z axis (azimuthal rotation within the sample plane). - - - - - - - - - - - - - - - - - - - - - Specify if there is a lateral offset on the sample surface, between the focal - points of the incident beam and the detection beam. - - - - - Describes the order of respective beam devices in the optical beam - path. - - Everything object which interacts or modifies optical beam properties, - may be an beam device, e.g. Filter, Window, Beamsplitter, Photon Source, - Detector, etc, - - It is intended, to include this functionality later to "older" beam - components, such as NXsource, NXdetector, NXlens, etc. - Until this is possbible, auxillary beam devices have to be created, - for each "older" beam component instead, to allow a beam path description. - To link the auxillary beam device to the real device properties, the - attribute \@device should be used. - - - - Reference to beam device, which is described by a NeXus concept - (e.g. for NXsource, entry/instrument/source_TYPE). - - - - - Reference to the previous beam device, from which the photon beam came - to reach this beam device. A photon source is related as origin by ".". - This enables a logical order description of the optical setup. - - - - - - This is the optical element used to focus or collect light. This may - be a genereic lens or microcope objectives which are used for the - Raman scattering process. - - - - - - - - - - - - - - - - - polarization filter to prepare light to be measured or to be incident - on the sample. - Genereric polarization filter porperties may be implemented via NXfilter_pol - at a later stage. - - - - Physical principle of the polarization filter used to create a - defined incident or scattered light state. - - - - - - - - - - - - Specific name or type of the polarizer used. - - Free text, for example: Glan-Thompson, Glan-Taylor, Rochon Prism, Wollaston - Polarizer... - - - - - - - Spectral filter used to modify properties of the scattered or incident light. - Genereric spectral filter porperties may be implemented via NXfilter_spec - at a later stage. - - - - Type of laserline filter used to supress the laser, if measurements - close to the laserline are performed. - - - - - - - - - - - - - Type of laserline filter used to supress the laser, if measurements - close to the laserline are performed. - - - - - - - - - - - - Properties of the spectral filter such as wavelength dependent Transmission - or reflectivity. - - - - Which property is used to form the spectral properties of light, - i.e. transmission or reflection properties. - - - - - - - - - - - - - Allows description of beam properties via matrices, which relate ingoing with - outgoing beam properties. - - - - - Sample stage (or manipulator) for positioning of the sample. This should - only contain the spatial orientation of movement. - - - - Specify the type of the sample stage. - - - - - - - - - - - - - - If "other" was chosen in stage_type, enter here a free text description - of the stage type. - - - - - This allows a description of the stages relation or orientation and - position with respect to the sample or beam, if an laboratory or - an stage coordinate system is defined. - - - - - Description of relation of the beam with the sample. How dit the - sample hit the beam, e.g. 'center of sample, long edge parallel - to the plane of incidence'. - Is redundent, if a full orientation description is done via the - stages "transformations" entry. - - - - - - - - - - - - - - - - - - Type of control for the sample temperature. Replace TYPE by "cryostat" or - "heater" to specify it. - - - - - - - - - - - - - - - - Hardware used for actuation, i.e. laser, gas lamp, filament, resistive - - - - - - - - - - General device information of the optical spectroscopy setup, if - suitable (e.g. for a tabletop spectrometer or other non-custom build setups). - For custom build setups, this may be limited to the construction year. - - - - - - - - - - Commercial or otherwise defined given name of the program that was - used to control any parts of the optical spectroscopy setup. - The uppercase TYPE should be replaced by a specification name, i.e. - "software_detector" or "software_stage" to specify the respective - program or software components. - - - - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - - - - - Description of the software by persistent resource, where the program, - code, script etc. can be found. - - - - - - - Pre-calibration of an arbitrary device of the instrumental setup, which - has the name DEVICE. You can specify here how, at which time by which method - the calibration was done. As well the accuracy and a link to the calibration - dataset. - - - - Path to the device, which was calibrated. - Example: entry/instrument/DEVICE - - - - - Provide data about the determined accuracy of the device, this may - may be a single value or a dataset like wavelength error vs. wavelength etc. - - - - - Was a calibration performed? If yes, when was it done? If the - calibration time is provided, it should be specified in - ENTRY/INSTRUMENT/calibration/calibration_time. - - - - - - - - - - - - If calibtration status is 'calibration time provided', specify the - ISO8601 date when calibration was last performed before this - measurement. UTC offset should be specified. - - - - - Generic data which does not fit to the 'NX_FLOAT' fields in NXproces. - This can be for example the instrument response function. - - - - - - The overall resolution of the optical instrument. - - - - - - - - - - Minimum distinguishable wavelength separation of peaks in spectra. - - - - - - Array of pairs of complex refractive indices n + ik of the medium - for every measured spectral point/wavelength/energy. - Only necessary if the measurement was performed not in air, or - something very well known, e.g. high purity water. - - - - - - - - - - Properties of the sample, such as sample type, layer structure, - chemical formula, atom types, its history etc. - Information about the sample stage and sample environment should be - described in ENTRY/INSTRUMENT/sample_stage. - - - - - Locally unique ID of the sample, used in the reasearch institute or group. - - - - - State the form of the sample, examples are: - thin film, single crystal, poly crystal, amorphous, single layer, - multi layer, liquid, gas, pellet, powder. - Generic properties of liquids or gases see NXsample properties. - - - - - Free text description of the sample. - - - - - Chemical formula of the sample. Use the Hill system (explained here: - https://en.wikipedia.org/wiki/Chemical_formula#Hill_system) to write - the chemical formula. In case the sample consists of several layers, - this should be a list of the chemical formulas of the individual - layers, where the first entry is the chemical formula of the top - layer (the one on the front surface, on which the light incident). - The order must be consistent with layer_structure - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - 'atom_types'. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known timestamp when - the measured specimen surface was actively prepared. - - - - - A set of activities that occurred to the sample prior to/during the experiment. - - - - - Sample temperature (either controlled or just measured). - - - - If no sensor was available for the determination of temperature, selected - a nominal value which represents approximately the situation of sample temperature. - - - - - - - - - - - If temperature_nominal is "other", enter here a nominal/assumed/estimated - sample temperature. - - - - - Temperature sensor measuring the sample temperature. - This should be a link to /entry/instrument/manipulator/temperature_sensor. - - - - - Device to heat the sample. - This should be a link to /entry/instrument/manipulator/sample_heater. - - - - - Device for cooling the sample (Cryostat, Airflow cooler, etc.). - This should be a link to /entry/instrument/manipulator/cryostat. - - - - - - Arbirary sample property which may be varied during the experiment - and controlled by a device. Examples are pressure, voltage, magnetic field etc. - Similar to the temperautre description of the sample. - - - - Medium, in which the sample is placed. - - - - - - - - - - - - - - - - - (Measured) sample thickness. - - The information is recorded to qualify if the light used was likely - able to shine through the sample. - - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - If a thickness if given, please specify how this thickness was estimated or - determined. - - - - - - Qualitative description of the layer structure for the sample, - starting with the top layer (i.e. the one on the front surface, on - which the light incident), e.g. native oxide/bulk substrate, or - Si/native oxide/thermal oxide/polymer/peptide. - - - - - Specify the sample orientation, how is its sample normal oriented - relative in the laboratory reference frame, incident beam reference - frame. - - - - - If the sample is grown or fixed on a substrate, specify this here by - a free text description. - - - - - - Here generic types of data may be saved.. This may refer to data derived - from single or multiple raw measurements (i.e. several intensities are - evaluated for different parameters: ellipsometry -> psi and delta) - - i.e. non-raw data. - As well plotable data may be stored/linked here, which provides the most suitable - representation of the data (for the respective community). - - You may provide multiple instances of NXdata - - - - Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) - - - - - Spectrum, i.e. y-axis of the data (e.g. counts, intensity) - - - - - - - - Location to save the calibrated wavelength data. - - - - - - - - - Parameters that are derived from the measured data. - - - - Light loss due to depolarization as a value in [0-1]. - - - - - - - - - - Jones quality factor. - - - - - - - - - - Reflectivity. - - - - - - - - - - Transmittance. - - - - - - - - - - - Commercial or otherwise defined given name of the program that was - used to generate or calculate the derived parameters. - If home written, one can provide the actual steps in the NOTE - subfield here. - - - - - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - - - - - - diff --git a/applications/NXraman.nxdl.xml b/applications/NXraman.nxdl.xml deleted file mode 100644 index 02290711d..000000000 --- a/applications/NXraman.nxdl.xml +++ /dev/null @@ -1,261 +0,0 @@ - - - - - - - - - - Variables used throughout the document, e.g. dimensions or parameters. - - - - Length of the spectrum array (e.g. wavelength or energy) of the measured - data. - - - - - Number of measurements (1st dimension of measured_data array). This is - equal to the number of parameters scanned. For example, if the experiment - was performed at three different temperatures and two different pressures - N_measurements = 2*3 = 6. - - - - - Number of detection angles of the beam reflected or scattered off the - sample. - - - - - Number of angles of incidence of the incident beam. - - - - - Number of scattering configurations used in the measurement. - It is 1 for only parallel polarization meausement, 2 for parallel and cross - polarization measurement or larger, if i.e. the incident and scattered photon - direction is varied. - - - - - An application definition for Raman spectrocopy experiments. - - Such experiments may be as simple a single Raman spectrum from spontanous - Raman scattering and range to Raman imaging Raman spectrometer, - surface- and tip-enhanced Raman techniques, x-Ray Raman scattering, as well - as resonant Raman scattering phenomena or multidimenional Raman spectra (i.e. - varying temperature, pressure, electric field, ....) - - The application definition contains two things: - 1. The structures in the application definition of NXopt: - * Instrument and data calibrations - * Sensors for sample or beam conditions - - AND - - 2. The strucutres specified and extended in NXraman: - * description of the experiment type - * descroption of the setup's meta data and optical elements (source, monochromator, detector, waveplate, lens, etc.) - * description of beam properties and their relations to the sample - * sample information - - Information on Raman spectroscopy are provided in: - - General - - * Lewis, Ian R.; Edwards, Howell G. M. - Handbook of Raman Spectroscopy - ISBN 0-8247-0557-2 - - Raman scattering selection rules - - * Dresselhaus, M. S.; Dresselhaus, G.; Jorio, A. - Group Theory - Application to the Physics ofCondensed Matter - ISBN 3540328971 - - Semiconductors - - * Manuel Cardona - Light Scattering in Solids I - eBook ISBN: 978-3-540-37568-5 - DOI: https://doi.org/10.1007/978-3-540-37568-5 - - * Manuel Cardona, Gernot Güntherodt - Light Scattering in Solids II - eBook ISBN: 978-3-540-39075-6 - DOI: https://doi.org/10.1007/3-540-11380-0 - - * See as well other Books from the "Light Scattering in Solids" series: - III: Recent Results - IV: Electronic Scattering, Spin Effects, SERS, and Morphic Effects - V: Superlattices and Other Microstructures - VI: Recent Results, Including High-Tc Superconductivity - VII: Crystal-Field and Magnetic Excitations - VIII: Fullerenes, Semiconductor Surfaces, Coherent Phonons - IX: Novel Materials and Techniques - - Glasses, Liquids, Gasses, ... - - Review articles: - Stimulated Raman scattering, Coherent anti-Stokes Raman scattering, - Surface-enhanced Raman scattering, Tip-enhanced Raman scattering - * https://doi.org/10.1186/s11671-019-3039-2 - - - - - An application definition for Raman spectrsocopy. - - - - Version number to identify which definition of this application - definition was used for this entry/data. - - - - - URL where to find further material (documentation, examples) relevant - to the application definition. - - - - - - - - - - Specify the type of the optical experiment. - - You may specify fundamental characteristics or properties in the experimental sub-type. - - - - - - - - Specify the type of Raman experiment. - - - - - - - - - - - - - - - - - - - - If the raman_experiment_type is `other`, a name should be specified here. - - - - - Metadata of the setup, its optical elements and physical properites which - defines the Raman measurement. - - - - Scattering configuration as defined by the porto notation by three - states, which are othogonal to each other. Example: z(xx)z for - parallel polarized backscattering configuration. - - See: - https://www.cryst.ehu.es/cgi-bin/cryst/programs/nph-doc-raman - - A(BC)D - - A = The propagation direction of the incident light (k_i) - B = The polarization direction of the incident light (E_i) - C = The polarization direction of the scattered light (E_s) - D = The propagation direction of the scattered light (k_s) - - An orthogonal base is assumed. - Linear polarized light is displayed by e.g. "x","y" or "z" - Unpolarized light is displayed by "." - For non-orthogonal vectors, use the attribute porto_notation_vectors. - - - - Scattering configuration as defined by the porto notation given by - respective vectors. - - Vectors in the porto notation are defined as for A, B, C, D above. - Linear light polarization is assumed. - - - - 3 x 4 Matrix, which lists the porto notation vectors A, B, C, D. - A has to be perpendicular to B and C perpendicular to D. - - - - - - - - - - Beam which is incident to the sample. - - - - - - diff --git a/applications/NXxps.nxdl.xml b/applications/NXxps.nxdl.xml deleted file mode 100644 index 89a4065fc..000000000 --- a/applications/NXxps.nxdl.xml +++ /dev/null @@ -1,510 +0,0 @@ - - - - - - This is the application definition for X-ray photoelectron spectroscopy. - - - - - - - - - - A name of the experimental method according to `Clause 11`_ of - the `ISO 18115-1:2023`_ specification. - - Examples for XPS-related experiments include: - * X-ray photoelectron spectroscopy (XPS) - * angle-resolved X-ray photoelectron spectroscopy (ARXPS) - * ultraviolet photoelectron spectroscopy (UPS) - * hard X-ray photoemission spectroscopy (HAXPES) - * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * electron spectroscopy for chemical analysis (ESCA) - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - - - - - - In traditional surface science, a left-handed coordinate system is used such that the positive z-axis - points along the normal of the sample stage, and the x- and y-axes lie in the plane of the sample stage. - However, in NeXus, a coordinate system that is the same as `McStas`_ is used. `xps_coordinate_system` - gives the user the opportunity to work in the traditional base coordinate system. - - .. _McStas: http://mcstas.org/ - - .. image:: xps/xps_cs.png - :width: 40% - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Link to transformations defining the XPS base coordinate system, - which is defined such that the positive z-axis points along the sample stage normal, and the - x- and y-axes lie in the plane of the sample stage. - - - - - Set of transformations, describing the orientation of the XPS coordinate system - with respect to the beam coordinate system (.) or any other coordinate system. - - The transformations in `coordinate_system_transformations` depend on the actual instrument geometry. - If the z-axis is pointing in the direction of gravity (i.e., if the sample is mounted horizontally), - the following transformations can be used for describing the XPS coordinate system - with respect to the beam coordinate system (.): - - .. code-block:: - - xps_coordinate_system:NXcoordinate_system - depends_on=entry/geometries/xps_coordinate_system/coordinate_transformations/z_rotation - coordinate_system_transformations:NXtransformations - z_rotation=beam_azimuth_angle - @depends_on=y_flip - @transformation_type=rotation - @vector=[0, 0, 1] - @units=degree - y_flip=180 - @depends_on=y_rotation - @transformation_type=rotation - @vector=[0, 1, 0] - @units=degree - y_rotation=beam_polar_angle_of_incidence - @depends_on=. - @transformation_type=rotation - @vector=[0, 1, 0] - @units=degree - - - - - - - Description of the XPS spectrometer and its individual parts. - - This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. - - .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - - - - - - - - Reference to the transformation describing the orientation of the beam - relative to a defined coordinate system. - - - - - - Incidence angle of the beam with respect to the upward z-direction, defined by - the sample stage. - - - - - - - - - - - - - - - - - - - - Azimuthal rotation of the beam from the y-direction towards the operator, defined - by the sample stage. - - - - - - - - - - - - - - This should point to the last element of the coordinate system transformations defined in - /entry/geometries/xps_coordinate_system/coordinate_system_transformations. - - - - - - - - - - - - - - - - - - Reference to the transformation describing the orientation of the analyzer - relative to a defined coordinate system. - - - - - - Polar tilt of the analyser with respect to the upward z-direction, defined by - the sample stage. - - The angle between the incoming beam and the analyser is given by - beam_analyser_angle = beam_polar_angle_of_incidence + analyser_take_off_polar_angle. - In practice, the analyser axis is often set as the z axis (analyser_take_off_polar_angle = 0), - so that beam_analyser_angle = beam_polar_angle_of_incidence. For magic angle configurations, - this angle is 54.5°. - - - - - - - - - - - - - - - - - - - - Azimuthal rotation of the analyser from the y-direction towards the operator, - defined by the sample stage. - - - - - - - - - - - - - - This should point to the last element of the coordinate system transformations defined in - /entry/geometries/xps_coordinate_system/coordinate_system_transformations. - - - - - - - - - - - - - - Reference to the transformation describing the orientation of the sample - relative to a defined coordinate system. - - - - - - Clockwise rotation about the sample normal. - - - - - - - - - - - - - - - - - - - - Polar tilt of the sample with respect to the upward z-direction, defined by - the sample stage. - - - - - - - - - - - - - - - - - - - - Azimuthal rotation of the sample from the y-direction towards the operator, - defined by the sample stage. - - - - - - - - - - - - - - This should point to the last element of the coordinate system transformations defined in - /entry/geometries/xps_coordinate_system/coordinate_system_transformations. - - - - - - - - - - - - - - Peak model for XPS fitting. Each `NXfit` instance shall be used for the description of - _one_ peak fit in _one_ XPS region. As an example, this could be used to describe the - fitting of one measured C 1s spectrum. - - This concept is related to term `3.29`_ of the ISO 18115-1:2023 standard. - - .. _3.29: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.29 - - - - - Input data and results of the fit. - - - - Dependent variable for this fit procedure. - - This could be a link to entry/data/data. - - - - - Independent variable for this fit procedure. - - This could be a link to entry/data/energy. - - - - - - - - - - - This could be a link to entry/data/energy. - - - - - Intensity values of the fitted function at each energy in the position field. - - This concept is related to term `3.15`_ of the ISO 18115-1:2023 standard. - - .. _3.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.15 - - - - - - - - - Area of the peak. - - - - - Width of a peak at a defined fraction of the peak height. - - Usually, this will be the Full Width at Half Maximum of the peak (FWHM). - For asymmetric peaks, convenient measures of peak width are the half-widths of - each side of the peak at half maximum intensity. - - This concept is related to term `3.28`_ of the ISO 18115-1:2023 standard. - - .. _3.28: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.28 - - - - - - Position of the peak on the energy axis. - - - - - - - Total area under the peak after background removal. - - This concept is related to term `3.16`_ of the ISO 18115-1:2023 standard. - - .. _3.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.16 - - - - - - Functional form of the fitted XPS background. - - This concept is related to term `3.21`_ of the ISO 18115-1:2023 standard. - - .. _3.21: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.21 - - - - - - - - - - - - Linear background, i.e., a simple straight line from the minimal to - the maximal abscissa value. - - - - - Shirley background. In the Shirley background, the background intensity at any - given binding energy is proportional to the intensity of the total peak area - above the background in the lower binding energy peak range (i.e., the - background goes up in proportion to the total number of photoelectrons below its - binding energy position). - - - - - Tougaard background (or Tougaard universal cross-section approach) which is a - methodology for integrating the intensity of the background at a given binding - energy from the spectral intensities to higher kinetic energies - - - - - In case none of the enumeration items apply, description should be _other_ - and the functional form of the background should be given by the `formula` - field. - - - - - - - - - - - - - - - - - - - - - Atomic concentration of each species defined by one peak in the peak model. - This should be an array with the indices pointing to the individual peaks - (i.e, peak_0, peak_1, etc.) - - - - - diff --git a/applications/xps/xps_cs.png b/applications/xps/xps_cs.png deleted file mode 100644 index f83b15e7076554c830543acae2ff6f3e9960e395..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 148952 zcmXtA1yodB*G8Hll>wwdBqgOw1f;vWq`SK$29y?%?(Xhxq-*F7>F(wq=Ka65WVwJl z=bn4cK6^j0FTdnv#n1r+02mk;bP4fqiZCz;1u!shw8)4sFmK{Ww|+o=@y1b6ObDiI zlxPp~4ZNwKj35k5WhCmO0RrTE6gzPZM;I8qx36Ds2B|ItU|?QyCB6wNyXhW2p)cX6 zG`>XMsL`EgtgG?;Mrxn`twfaVW0dlF(-NGS@ez}lmW3? ze=`3}*sizmK%6sNas@%#x4;byL0bg)Kf!k=V}}O|o=48*iTq=pCf8R!t!1+%8r3Ev z-MWq=rsW!#q?48Kg@8v>X`cbi9-(B*c)J zrH%L-34@3k*JzriFr&ikTyt@21&rHFRxICgb-SfUh+1tSguleY2)5Fyx5+IPiUvwm z!S*gD0IDnmZcWrAX?GElj{LM#l>p?luQPNbEJ=F3zwroBJy<a7CX{;GF$TJ;F1JZrAS>giVH11}F(kS;Sv(1!hnU-od zM$ZfmC$WbL)n?k2{gH2Z+lp1se_s%C_2A>mk~=KmA$X;jFdr?%)S}ajTdaR)sv1vo ztKCrEv|kh=6vjNPJl6Umgs{VrjWQes{EQ>Gim+%SSVdNHV(L>_hb5ap8h#(}LpWkj=OI=qsp0$|t>|A$;9Sz84=cb!PN zstAJqwyPOQqyR4LC|VkD(U&0L`eoC$C?DEc(V;jh$gwzZLub9~z{DNCJ{XlIxRS`H z^F->*$~uB4Pb4J@?R92eDv*6zuF&?ls0e9j$;4CC&Q>Cd+jk-72Hdp13n?EoeX)H| zeB)BZcQ(S5u0fa4emgOpTQOiqXwdSUoW3gEh%BLxXM_`S6R7*MvbkyHaxFae^FskB z4t=(`tT=iztc+i3J!ialBjZmaLFCyTwrO-1yQTHRBaeI|E@2Jl!1 zb}}To-&Dzd}kIUJ->OYgs!iL2>F*`pZQ z&x2+y0Cvmd0Q!VV(yVai`Iit_NL2-CeqBZb5!cIxV_S$-e*7fgVp~yM$XpypSw`$- zSokB$8!4_q)Jt&7?R~i+VZZl5v8e*15W`pQvL73826TU$xT{RUjZ@t|lma_=0_u<) zcP1r2+r3dK-fpm~UU#W1Tnt?BchG**i^bsCBEQj*7T)KG2Yx%F z2q)s6RM#)Y=UF#Frv)3VTg~?EOk_R&wj-1V%??!k1nx8UT&C>yoKc{2&$ceJ(Mz%O z(kT{nXPDwEkw;#Lea11VD|t8j#B)?LMWf6MO(nx``y*={cVqz?s_~3En!w!>FX_+Z zX*}Pn?gtSYL}fCeDa2pYm&R9D0Oz5M#SlsPz`}-V>RbL>;pJG7LD=-~-WMl;Bkau@) zt3>lfITB-gIMI*^!B#)1i%n3Z5v_L?Esn6+RNI1SwXwF{+W!1BwtZfzR=;=`j=^T3 zMq*1Mgf`9yAw({WIrwpH8qxAZPfYXV@s2Nq)@`1p_%K(K>uvwR{X4r%+(%ZILv=uI zFmwl%?QT0B>UK;VA7b7k+&2s!X4-4b!SJyc%#tHdVhq|N0Mls-;1Dg|%&_z}PE@Sn zSneASSuvG(?x@WkRm2z7<4*S9TYHv1E9q7Qt=<57fty9p`BIM}5t2GGG}s^P6X<#r zHLm};p-~epNCa;HBGq;` z&t$ot002eMZ|C~Je)D<;IvhK~a#7&ndhU-=_dNB~{n%^an|5nwUoYFj8H59vTFRe0 z&KW@}(D3FbfpZN2Yj)@m%4A8L#PHUjV1a1+Cw!-X*X4*L62}n7nrfMz#&}qWFgYNM zf9mxxkWz@e`&UGZsl{K`kUF#U%OWRVGvMK>-@Ug_$4BGxa_IV5w_)!O5-m8|byYw- z)9AkyphdzYu0s9r^B`7QU?GTqktUYE1y`uuE;8-}!*<@$>~8c5SOgEc3r0U#@V!1Y z#W28@^}Xy;q#pnPNx4tK%=N;L?t*Zj4L{S3Y11tczuo6sWX&NAdz>wc$J6@il5Nak z^iT_OPA4eJz&1S29#i_8So;>!KU>cvKNoLNs>P+c;{nOyLerGWR#%#QXrcPV`+osB zhf)+7@Y!mP8KBaIplN&+R0=H8yS&50j|n1SUv<|MEVFI9Y;;Ihj-&h<9tofuG^Y9D z0G?IROgqMS@q7as2Jc^CDBG$JUC6WGm^~-J+O(ZW0H$%F7vidxc>WRU9Iv%|zisUs zBD7~Rx|*IL?{K+05g=r|WWoLDFi6o%{K6;t2FDnIpm8TAbgVvJ{beYQawf4jL@$

xZElWG?ia?G+h4l_E(7|-2#T^(D+1I*AtK2h`F8G*O zf}PdcRR_`3cDaciv`lDBj!* zE+w%XKFU?Oggpw@yx3>y}o|CIQ)c>x-Mlq$vjv6$dLT z02LnM$!yst(+D)2B6vh0l^-{Yb6dpbg=R&B_VcZEl8+6qccQrm^At zlL}HF`O_3W&JMXySaiqx#GAu;Lz#I+t2Aaek6hQ|bFhI{Bod{BxAki+FNa|#k0LL4 zqhKiz4J%AdE1&7=+R{vAaci{@t6XQ?tkYq1H+~pq%qsS+~k}spO^!1Qg*Hs zO#OjZ8ah!f|D)aQo>L3Bf0Cl~m<2%BDLrmn7XIhqNL0VzOMorG9u8d=>$ODpLP?Ag zM;YY&UrF5$u1bHa>a4wDgpB(*N2_reG{0GjoSITgV5Y|I*moU}Ht4+=1YIrSjMdP9 zIY&JE?)x%Ml<0idUH}WW6)YC-y#cLkg5d;^Ai)~Y!&XsusDM{M^&(1WsX?jDGn%{j z%#ntz9W~bE>q6^wJmPp{jMef*zV-(+wVC?Vg0v$UnP3U()Nht6_VMT;e-!N z8Bwmvk?2%Q*D#>R^;{W=nbUKYZ?;2kq!9@6zFXuC*#^UhNa{oLopAMe;~;sS|BspP zXn^ZZ;_yQAp|{TQHPz*<$wJSK_kX%)l#$%qudR1hL@f-S^RoqHD;d@~D2tX1EF*?LpP!XTWrv=FPT?(Cpmwiu7ac#L>Z; ze`>E6Ik$4w3|K+v6)T8!-IO(j3a!`?nv^_cxjkD`t0+YScSrn%3S5@Z;m#*Xao6(Y z4FefCKQOwSdG1TuB+6yR=>xbE$`YNUZ!ee24PZe_^EWFwh3mvP0H``(<)0RQa* zsutBf_d+)2aDT!)ngs+6&;|viG}C$6r{PWK9?)WNN`~Ro9i{Y(@L!24E<~{GIJd=C%W;HAumfxJ{;aH6sO-B+-ea;_nF8+e4&kYl;#&K7|)t`YdOi z={nCJ-go=On{M%TH4MU zNPffu4H9vARZx+(Kr=&+JgO@JpeFwJ?+pv#V}z?Q3kE<|-=D_{zaW=m=#34< z08Y+e&yNTTyvnhV!ey1g83Hu({ix#^>p%1^P{SZ?vi9q18SneaO1yA1ky3D_EKpO0V;=B;3 zr4QjPC_+gPalvGx=U1P9iDnde{=OgE4PqfR=)6~my~1-NT$iA-zI45zw9fGpiw*GXbkVG zPdD6jw3=SNJ~D~+x`eg?Dy?J`vf-eVb*&^#)(RsWuE4WOnKL% zh3PM(?}OKk8}(N_EOWKLy|)kB|GnbabE8>fF)}H_ubq}^QAa0-g%e`2h^jC?cwCvza zy~rF(7MsuCSAEh&2Xs*g5gFFIhCujveVym8m{|%znW2E0Kdrv-z}|0jH^%bZeJ_K| z(Ie2A*k&Qv7%~4J+x}#YUMWqA6eaK^MDs^wXw#^@`!|M+3OSP1&NfwcSv}KaR#S|B zA9`eDA}Zh_Xw}u9u6}V2X?>ie&5z%3;uW^U{P6KVu%yy(`dswlN(W$F z%s5FEq`i29H#(24%H?6$lb!LhA*QC*gF5gX3QGXdMWBRP&&Ph++=dor&&PAcH~$DQ z=W>coox5Rh&Ceko z2nG)!$xNAuj`u5)? zeacbJLv#(q7H?EgOKb{ICN={X{!>6eg=EFsyjtwu6-puStx+31()Lysd`6-2gn)Jt z$fAXIdN;i)bQ;;qmFWdE4HkaWN5iZ>@|6(+aY9E>MsyPn86&9ah`tjcHu=x@!WoN- z^|(EIA!{g!xIuSe$1$14AmaL3NX&KClV$%NULdyvvc*@Uc>=)&dmZf6_Fg}=Xuf@e z?!c=gVP)2ogfRY1iJ_&!ru)%2Rh+e^=U^ zSd%E=he|{GVA$~IaGXuuuRgcj@KRBM9si0!;1OwakQ4NQF+qkLKLw81G+8Q4&=DT} z27E+qXk57gA-dwliT4OBQfof{+=U9EgxBmB?IO+IRqcryP+cI1DMaJnpH>;*ASN`^ zx%u2H0f1(!X|Q{UPe?MLx+Ii6e<(~!8;GHe@{vZE9oT3w7Gj2$`fTBWszxPhKrSg7 zhap{06UyFyY%Ma(onz^pk^zM5#+8=mTnW7jI9^^xCGxDBjLDN(@~D4Gbdn=Hq3Lob z`W0WuJ3~Yz@l45_ulb}<{Guuv_Fgda1C;UK@K2tPZLK_r;n$PSDQZ-#JU);dmDQEJf`yDijOijk9tLrYiT_K0PhIQh$?{rHBWplg=5Xc5^IELFQCHuNz^ zzWRCZ%skiN3e0++d};n+>){f7wbHDj`4*4}MTK&Kf&qvM1;{yw0QMpDaj&O(S|Dag zwe9W1Bj6-ltFvC1_@e?TTjh%RD}|Yaim6|)GbX^ti%d01wp>%Xw(6%L?54wXylA36 z2fCIJ(LmB(-Pd^;gBK$M>*4N##t07joGeQich^0nb7{#(r_akZls@BS3wujgm`eSV z1!6@m_XTf3t9kE2h&s7nE;OJbA)iyo)l=dr7sGX_d69q^)#IHE9*}N zw|8OjCF?h>-$&f`Nv}O#Xqo1uIRE3JxtW=r79_LX9ygh1K#HwI%;gsj5Z&EoRcYG) zxObD#OE-X7JD!e-Ynb9__9DI4X1Pg$CKbA-Lc~?Z?f+>J&R!eL*1vGKN~^rGFW%D% z@^QXa4?XP3^9eZLcM8r(Cun0~i;A0CN=m9NDvXB)t!#K^y1HMQCv-)BL4{{VGYgCP zgMjvkY0r@$LhX)#jAJ~uNDJtVe*2rhm%ca^jPIf-QcB9L{H$k(h~NmO@&#Rh8*Sxj zNT4TXNl7f80A+eVrxo{@)5TYRxpDchbdmou!kP+f(Lu`5VySb#s~Go@98&e;2NT(iFqL{kFawP1aFR|H}Y zX)+anPRbuEiL0do4|?mr3e__^n~whVdRzu+&d0l+hZTC)hn}nVea60(uMGS9pw(Q3 zpU~a+?Mdfrb|i#{=j{lw!_(Wd&bIT71N~B{Olc{ZK-zj_kUg&tE8|hLbs0}R(oe}n za_tuxArb@>D9~$Pfvo`3L1gha%j>R+H13m!sbk6aA3$`4*TK;*U;88=*@EnxNh^eu z`b*=jmnXN`(MQihhwY+?nOZ`V$s~dMFW&qhI)li4_*C7EN4G<50A;@=@1UE zzug&^jqO)ntCRg$)W}}r!O^X^HaE83bOGFnFzB=f!H&G5#@Gj8CUh94Ea1Y=9g-u$l+hL)}Zv{U(;2+Z35syNviMj(!J#1;+uj7T< zPoQ(m=MHxe>RCFerkX;5fvg_lvV1Fh8&=kMu{GZ*Ovhy%DYgkOr&Z`X$Vy+9|5OiN zT7wN^`eie$rO{f8D@q*>3ywYIqjR?c@$*XM$o zqLeqytSE|H7e$jWI<~Ctm3fI_cxur<0r!X6m90E8F>VVkYKMmOFsenzNf*lN{s~!E zRTND2gb(BH7Z8*i)=<^>tyIo0IZeP@NLKY#3}7n!B^7+G*aO|we@deTJ!SZ2ZV8og zP>N(zJ_ih-C!_$_Mc>2h7r=cb9UK1y6=D7CdFU8Flwm;5LZQ-YX!_09O*N)XVeXUmwvL==G`k*U zvy-E#t=O4{3VF|lhznaCvLUpgRZNMmG@z^J|tP8>Ni6G)k1j?Aoc#kZg; zUNouUysj5`E*B+K=X@}O3nEZG+QC%Hh`EnJhNc$F2p*%u&eUWr;Bm&KWy06YN35KR zJv~DF=cznHo**6v>^8hL;fO+F7k1_!G~FUm!HO;iHAml|z{2b?3|j%UNkEtTz^2sw z^p_pnLB=?HtK26NL4%;f@w;x)=dYRH+bY}_)3e^caJla_1jS{)CeMQ)ex%26iMKnJ zPS;gCG(aL?huVi*IrLu;;gvFEh0|UbN)bmrEkmYx)xRr_(?|6R+IIb5QA|mwWk{4; z5rpz7giflTd8O=7WKpsvm;T((B(tJfPCI|2>tQL|k`a-{X0nd!S=dL8_Ha;fBme0KGgEIkkFL>n(3N+O<^$ckl?L17>SffaeS0ZnAScVSg6u*I<_#S(L zbRLv8*J&N#xol|*mXZ`c-qsxY$UykGGhKx~NMULN?#_3q@ORwQ() zLW6S^`BfMicF-`yQ-rm^NLm>h{h4k4pH>&HIdf(5_P6zOW)?lNKbaBU`K~`1vQRjg z>mge11-wbtZO;pL-$MQ2%wN-7EO@~JwZFu?!h1x5(aTcLM!crW9+$gNo zO4Qi0Z;p=D)Atml96Tm5_*IZkV0p=3_A!#Z-By_AvGt#L>&Y@G3i&be*9pSrAK!L- z4nBz@9rm}4pM87y0lBrm0Q3e{Dpn31K32V?E1A$#wIj z6Tdr+%bL)n`A12Gtjr-us&z(FN`;NimKR>EB443@QBO{(RC_QOyC{82G0E;7N%jq) z(a@A8^=%Af7!?e1@EaO9svW|<9BmYL*tR(w$(_Goy>wfrjv{hG`kip%$?t?{M^&Kv zt-llzY&;7zr3X8*^?7pXvSPr%Lj}k($n&U0Jh&y}j^60WakT+OIrceXbRZH24QHnA zuJ86(SOmMxg?b4BIs4q`9J-_$&PR4`{r7cOPolFS4RvCqDwP<*YEGG7+}7fz8Hjcv z?6Cf4=)$W^k?KcggtUm?EV#!vQKV9gJBpXbYyQ4!W^;~!fPhAf+*ZGWF$PZMNGdc|uQc!a6C0(w-2usMYb z!(eBOi+5y)z_BHdgHnhuJ92mQ+6J+*&d2hLFFOs+kcWfU7-w05qMU{*e+&-fxsH*0 z(VNEa88(U+L@#qjh3e);4qB^c;~t0byNde4X%h8xeghGaCT0$Z|HTvP#cVl4@6NFw z)^&1(k&F6m^RQBMXK0<|#a^=`LuEpc_P7eMNe4Q`CjVKzMucUs$uj{lqvdQgxD3`NNJ?q%5 zU+Ol*^$%a1&x`Pg8YR=p7>p$44Q#v**o@%6o>NqT+W=c2uoK5=|M@|A4VUuLowEs}SJjb|&Qg#_#J=_Jf$4*Es*)eiXIf zfr4a|)Xt;UC-I^;T8~k@-`p-dZxclXaMMF9iAP{$?9gGs*JYKr?OE~kaHA9ExA_3d;JCaEkp zz})ch_ACMeEXOCk+DH06^$VM*wl*ZrfrE9Bjre@3*1zRt59zZ3HJ4X!Ub=DA%;QcX zBz16e%VT(2hvfUPrEqxo(5{%TLip2!h7n%b3XC?6-+@Xo0Hz4#lB+}J5KM=%QZ_?e z{D3^4ahlvHy!YXCNUrx?7S#Cp7E$lzUI zUA1brHTuNQPTavq5JV7@Zo?3<%#t3YD!B=`thJ0vkv{=_KDpB9&@Va6M{08EQRg2T zk=i-}|51TMBE4?2MUeokwfA4gg!xAYd!tQId%Y23jyGdPp%13bySW4pDF= z1jW(oSX}}pDPfbA6I06dx?3WI_)=UJ%tes~gFXbT1nf68>9Bhf?pH4d@mNpgp{Ih# zz<8&NZG4w6E7SCJWzz5kVA;+T-0w^f+dKhcwF#CwsR|X z-YfkBuyQSNV0PGi{cHDoA0`aPVk{-XJ=yeUK1kX`hR#39e@eeUOk=Fs^+Z;S?}yZ> zCw|IGO*%oa1%}JxTV?mKCFY^~@h5My(z-P*zhk~^w#U3YH+9Jn9YzVMyLXRo^bP^J zL+}ZaW16*thx)AkdxDbp>jc~mITLsrumM*i!`&K|C zcaZ9&+yV(f*iX)zzJ5sMkX&qWXC+qniETePAGlP>8q2s`V=49q;fpgps{=mS2&STv zQq1&rL3VfqM*+Xxkj0>mIIKPR|F3PWpkUnLnF!>JMG;*Pr#((?kru?gPJssiI? z=tmC06QbU(W$YIV{iQo`ttP}gZVA`oB<)PCkRCz}9RW3>{%lBt5%3eTiNm(bhs@n@ z9mq(X=J0i#<#$=uBeTBE-&>Qg`&{Py7%WSdSs81u`9IG`a2`coak*Q~AZ7;ykF;xe z7yxn^2AZJQD}IWU^aOZ#ybifb5MYgpO$SYbdT zlJ7(C5m&TW$8_5qEng;GB8EQu-p{|Na@qZ0DNvE8XHMpegLF>PwcavM&;?g+IZKa* z{8Fpz;mLms-$@8E?IV_qmwLqnnU}Dp+z>rW^HUjXdD)_1=J%F;ZTu1n;(o)z9aqB_ zgqd!oXHk|vTP?`Q?0Joii4czz3T&|X&O3+X)NNNEpA?B}^`x+0ed8!rd9XiLU}pf5 zl6V2)D{9d>o;c9I`Ett(z`298?_?W#yV_fulGrPD8Q2%ch}I(MQ-{-GFlBJ1dYuor zyq_i$dQucCqkIR2SH-9qWUB;EwE!_MvoXenePXayzeu;gn$_k$8ka?&Lh8D*NY|Og zRWMoLKS=Y647sn&+JH1VJCxn-3t$nX?J33I`J|l6|dJDx(;(2#@E-JD{XM^9^ZDsueJT zgC2TVo3colnluQm{v3)-S*k0TwO+(3vrIR;0Q27v|?h zEW{CD5U9M@zVgEiIIPLV`Ps45*gE;E7=slBycxNm>~7WLeUVvT5)f>`2@D{GqRMy_ zc}zfXr>ro)H-_N=F;jyu;%su!p2|5-#*_@Fif!eG01XsD`+KtjRk4nZy#Az(vkrk3 z_tm5ut4gFCf^-)^+W@ho+Raueh8j@?7PX)@67Mlrk=$tVebxl+rn)`X!EvP8j6rZN zH1>u3GMpPVgi{)@f?g$78luC70H42X)4a*bH3JIW6Il=~e_8k>mgoe%yhUwdLB#gX z-$}sAEq-QjvGN<=`34{E$?0>-Z(f(6Nn=E1--40$+jnkOfVJ9ypkHV!(eKdF(Se^? zzxN;mP=uJ14ENuSk}@`yx%X;aXCVlmxF-rtujBa*DCDER)|}Lg@iuQyfN^k{PP1YG zB}BH$j3Ub+btyY6(OYVp^*I0I8uE!78UT#gUnQy?ww3x7Ri

x9Vj2Ef0dcPrUU< zyf57kx==1kY_+fBqjfmUGp}|K&}Xvp_3CCgZ0eI%=y|0A(>On!{II%N%axwilpIfFs2HaYUow0zx=LbcSrspe+9GKhBw8xEVMy0#Vh)Sj>2 z-njWTgf>7!t!To0uNU~vq7&1XcZkujnA0jZ!RgK0bEb6O=M!*E>ir_K&Cod1PkI^1IQlis;4AE=XvN7mdH#N$9QLLy9&I&n%G`q^|}{M_xm ztYPN4B&5}lCYA)89(e*HTqY$o&~X^@Iv8BURSLtRq|w9tQt3BSB@;DZx}Kpyro4I9 zS6><~^KSjJ+iqM`X1d4x(@$bBk5=UeHJE_|4ZDuGJoI*peBS@_B86`E{0N} zcv@wUI;sk*eg_Ps6{%RY6w>{?w-dTgLB3yqFl~OL!9Sy$m1H*7c5_rAZ{(wNWy`Tk zy9+8v(^H+&fE<+6hIUNKi@uE77#eW2QoNpQ=Iw;QXpQGCA4Hf`E7t`AM59^h>R%PV zKR_Qr0M4&!95DvnpSAEW^vW$oVt+~?#;&u?gas)IOCMt20y1n8wud>R+5Oj_bQopF zr;0Msq9GXb2p{i<;=b!J#-(d}wGksC7mpG}ENm^6FEdwnDWo@A)D$aWhNziVI>fhk z!h=2Z+5_ijQI+zfGox4~II4x4ms|X=Pjz>nz|O#P(WGFob5g0^(dEDG3>Kc{g1cmM z27-MVAPh8?l(Dyii?1_)o_K0gIi0&I2kX8uu2LxWBLli!2YchJwxd zH+p)<7{nmr*29Xc7v4(jf4ZVaz5Cl4F=i)An<0y|vA)nM_#t509eDX@d?ichlh`t^ zHO1Dh*CylqS0StDbG<5&M2z!QwZ2MC>uQp~oTU~!0ijmg?&Z3m@AY>tLuEAl&w)Y( zGlhJ|0{jk9b;^pxqcmeJm#%<+c(3#25d&MG)h@tI6ML{D&&(?Xm)^T=&9A|Ix-)p~ zn2W-ng8LU3yr_XwPZIm+_bI%k!WaouB}nw4qo=4|H%nfs%&qW{Xq`R)%jhGo&U7{M z_`y2w7u_%InlU%~QBZV}ix}po@TrKFoaw69z(oIesgV^Fa=JQR;&e4S*c}@i!*O;d zwo*f!F2TU0*Onr5Tmr#r`%l^F8jxd+*O?zYj4X(Xq=QgGe zV4dAtZsr7q6kzaJwX&93M>b0Ga-7fAwL>dPL{DLc3Nw*m>D-O@&{fJa4+O}$ZnO6HbL(6^+W9u+jweq+cM_g;)P%lG@!E7TEWeV zK*$XJqF_7!8B&dE-&RKAKi*JGM0wLo#8jSIE5zQ6l||d;6Z)t+B=g=THQHD-gVY)T z$<&^lZSAqmZSzs!iMNL*YQNRz!(drX%T=Fg55pUz8GgC`o6hIIL3Z)|sKkvZ--GSh)y5R>z%D64>ftt0 zTJ322cPI0w`#nrglH?xrn(S>$nJh-4+b90a6hGakH`8dG$c{w>_KUbU|B+K{qiwY3 zDCAA&0yF+EG{M)0Rm9gTNWNk$e@zaJ2aAZj@~?t6!{-0>4{5l@3#m-nHqrE&{4CaRKXULh~qFI zUJGMGxmcA*5V1NkxyJXG-eNK`WA3bg=f_KljY*+XWf(UJE z2w^e|!@mGB2p{dS3U2%asJ^3YV*W&{qnyypu_J=)d{Ia2g@ge?Nge@QdMgOhkv-<; zW}2>Ww{9Ei{6iyihUt$4==;vrWfzwj4&RCo=^5)7UyP8*Es@NQdD0$LS>!KhQ?l20 zUPDeA9XgbA=CcN32(Mh!&9c1pwA{uyNcv;5A&C4iksH@DowOCvYYFLip9K2|SY3&O z;qlAxt`^~tL|;;=LIm5K)PkK=2a$zEsyE6Ipqr_@>CD*NQ1CBS&Hin#6!qR2>qgd$ z(idW`lob;bGlh-d-xQ(F3ko$<1ClD5Kxh>(hGn8S6y$F1lw3rWsM!!l_0f!ZwAZb; z-ZQ5*?~lrzc*kNB9?vZ@uW)c{F7s|Dv>KNb(E1+-r(GhUu}QVp4{Zzv5;@n>MR_=k zQ%O57Vw;o?t02K~LV)LhdO5opagF)mE(>bth~~64a`C}IJG4b-XCsNCghh=2dBUy7N6sWaL9x)t4BFD|k?j-*j3xGdrk7hUm1l_}Jm8-+$&~w_Zc&%sw1+^riKGnSjr@VkCZs7z?nlo8hyY zp*BmyVn=lEIKcxS_utewa`>&2`?qb0wz$>n^qph;$D{=X*Ztg!!cF2`?U*(ava2B0 zuk)FF;#YQ}*bm}WPaXuF?TZb4Fk*L_HJcimLzqyk;OzJO8w^Vw{vZm6wK z6Wt9ITx4&1W_y3{s#_iJE^1pGQPhwj`T3LnV=QT8s+8q`zpbSETSVvxjeWMCFxUjT z;ey)h&5>kq?aOKpJ;wA0>oO1WCpGbhiz1Nd$}JXci7yvDZx&_7Pn%oox;;5}HQ$JZ zIhHy%yE6)uA6j#Rnd8e#WU*wRC!KZ95-=sE#Aqv>K5#Jz`*s!xOJ z37?ZcnwGRA3Ee^IGoxbz|2KPHGxC>)krqrO2GT4L4f(5|G=#8`0pc>h>X?W8uMV}C zhUo1^A>TB7oi&Xu_c$q~>p^WagtUJ`|84li)Is&E87@!yBTC3<@KE+T zn#S+;cmBoP>90+m5&7$nGa!(rgYC35g0E{guvOF1@xC9711~8439^@sjy+@$FUrvF z^3`5rhCI+zwixECI~9P0nI{Z@{M6@lLEd?9ybu{WwfR`x{y14c0>U%NPhi7m{%4kj zhlh*q9L&=23fdtsgyPERT0U*>aBAhJx)AgNAnFa&U|JkVN+~Dxw5+^T1r}X&Fce#h zja>iQl&zR4*OSvifT*w@hIllo=tQLu|BQt}O0WRtpRn^}k;MGleH8L)y0GMcXR@_ zpVz=ZFX7i%Q-d8jgvf~H5Q9400SG^|zua6uL9SN)Dwt1ZO8(`C202dPQ6aLh7=fU^ zkNdN;sMz5&QAiQlmOm8ItH2-_I<)zWkb7p1e&uH7)@$eRd~_(5N#=+xCfoYY@Y4Jt zLj_qD_|7e-?z#Flk2q(D%%X7YALR{|V@!=MmJY&4)i{md92cm-Ot()mqZ|O?mG{ch zSXHu_^v%M1Vfx=;VlGrl`+ZXs0TjH>go`QMjx=JKY3glWjT4=s)+!;DWH}^ICQEep zJS%6t?xxr9(4=^)_S9||rgk)x@0H|$z5mPi0Zc2}PY^8AbWc)j*dO6!B={E>`jipU zX?*j$UX`EXtRp$b3JbI#uN%{fWs>}uV&eukluqRf*nV;s{QC|nRXHLINRQ&3;iX+c zUfUhXDM`P-n2t@B$6WgSXp>D5zSuUm_vzImAO`qML6jn#<+Gw7E3h;5pQBAXp`gwa zD~BwJImml7d-RY#>JGeSp}ivi9NE!Xpa8_S>vOx4O!t+B7zb68+XaSUi&@O1y&A}W zEBi^LGS`+oirE&YX=8OCe|v%#7gTx`T$wtVxB1D zTFkJ7Gwr{m*wjg>Cvt7R<^vG-!*f7hReCQVVJu4<+b-fzUhd1Ck!N9*`4kmE#b)QW zxU6YVH>qH|U^%v8Z>5q|r`{&DwFUAL^daTirTV^XeEr!OxP`m)UUALI;`vG(iaYom z2lM5adGw4BHl1tARcBQm(slK6mje0DuFCj{Q+I17F2WbHDp=x8Hp|(L;dsFi>v2H} zTc_EDoky1)!@aP9+k(Fog+Dy`US*1h+rpGYGi9gBx&$O!6a_Z%+ z0#=a%&Bg0y^wnZ6T95NzbO03LO*U1p@3brY{qX+X?ABMA<^E#!5vBTKx}^ajpq`-k ze~|U-<6g)c2BMReO5sB!aqGLvqh~@QV$Xv}uLK9|Dr6IVdxxw%x0*-h-fplrma2>l zQuk7bJM8Q(l1=z}U}0&MF4Hm26p{$JCZN3?;t*m%+Lk}_=uO)plNewcc=ML%wfn?o zM^Q3cCm(-R={_kfOLyeUll80%J;$^v)-wQzWFrHAW z&Ot@%=sx=vNUP>f-=ceA7l!(Xo^#QURQ5G4E~85ecn_WkqL;M(~Q(SjqGnXL?iOMIlA6sJfZ zb`@Up4k=*l7v!UCwhU==U3bq1DE*5g7hGZ8m3!s}Z_^^MC~i}wWr0D~KFz`1v=ptH z!ACVO5Hsa99SQvBytBRj*#sWF_ZW^lKLr^!z|M6LGf5#rh+w|LAYj68<7VrW$;YWS zJ6i=E;4wK}Ep=dK8vc}0#8)AMbuON11xeZ;40bWwjh))K!s5B+23{Qa{!!)pHjLyR z-Tfvra$IyJyE%<}*({U+v`V>EB{Cb}hT`-AXQ%>*LH*@NlSo zdXkMO<{SH{{q=Sk1(B+=XUVFBmIQEY2ETaBTkEqVjBoB2ZuZcs(CY)&M(LJ52k>SU zj4W`;5-%Z3wIU#{btZvj86kg@0OBt*L88p)aJ9W1w5fuQK^XkcnY~04EuSh7rak!h zt3gvX$Q_?{tY+Cfz0$CMQp1Rl>wCv&oWkt9yCYFjQ(>yKbVQOu@>OCT>R#@DGe(%_ z;nqvLRh8)`{_cc588G0Nlv1O%IRNLjECK3Q{$>fALeHyH<8A^fr8AgTxTq~YDsv~b zVGZX17u}m+sa{}B%B;IO1W$^L1|_yzuDjWDVPx}sTQ;eBb<^MYAW>5n^{X6EMR+T- z<|>rx?#!`;Pm^!OcU7-puG5jm?%v-5zsIOGN1Hmr6-){6D6? zIx5QV`&tF1OHw+dl$3NRX%Ru@LkUPpcO#87(g@O>L+8*TEg~S@UDDn4-huCLt#>W{ zT)wF6|tL#T`?~G_r&vW<4 zfxY~U6aYL2kt&Z1`pTg8|P#e#+mR)Yii_`Xfs7(Ifo6AO6fO=Z(CP#mGcb#%yNh>mL$mg!%8x zZ@hKk;G+-Q_ExYW_}vJ$mE+&3zsqjdBrZb!kHSd%NahE}3Yq<_>hfxkH&{hUrZ)aK zr+th|f^|n!sk=A`1aMm8cjYmlfPtyN|`x_eQGmt4wM!^&mG(`PQ z3-dB@BU4$nlpl=yS9V7~Q0SNHcj@l`)^+2 z2tTyV{8gmlwu-g8V^~XEe;tx?SNy2RqXQT2NO(&@D(go8n-MA4`Z7QTe#d<4_^&%2C#}+ivaH<^b~@Me`51W@uIU+3W6aD z`+(l>4~7nE{SmATJ*56EL!7(~bZtrj6@GO_#^B1jOcjvYaFADa05QOTSNX!J_kNvX zFcvS&nx`>w1cr)OiGnByctY*|cMmC)PrV704N$|&z_>ej2V*{25XPjWp2=h}*VIGgP&g?N-=Ked!VR#FMP2JB1Wd^2qUdLAD0frR;wPR zIxmF-8HmXqq{RnTU!X2oDE9&nmV^E;X|tKWi1Ad?%ZG*{W?FI@!}KLCB&C;7HClw6HZ)aGlcYACKlDHKHxy;v-~2gu zmKS-4FgDsBi!$lmZ2-9z6fwua97S8f-t)s?Y~Ei6up*K7&ZU|Dbm1^~SHRA06sb|D ztEp`U^dr0>F)?wS#g|F++#78obMFt>2BzpPq#3T~0E))ciNx=K8Sw1rY0{)(7c#lM zI%Sr>|C3Cl&_RXDq(wg`Tk_CnF(r|{eAaHmNRn(k%?tb+ z2ojA95bt{x6x_y(a6u-R-s2*F zxr=cJLp>5gLq~54O4$6%u<{{DS&hZG9ScC!h%DJcq30bQzOVXyS_-m03D1r)eD&`^ z`2iHAqjlN-dXlwmH;4SOsCDLD7JnUih--m>LjKT)E<8(t_g7Hn6Ouo-<9cCS5S@}y z0MYs_hl|X2|Jd%IUNIw?C`FaafAOUGA^Y6l>7}t01YHPrn#Y){l`hAyQ?oxIxBLMP zGSl;WKt$sFQ3sUqQBY7fjleU8S47BsQsI zd&JA0E=u~>7Txdk_fb(jd%eG`W@OWi;{mtM?+=T5<*$vS^?tHs?)SL)HgC2uXodqa zpOEpIr$yk#z|9(8PesW?x)bb=g$U&#(vt52(U|F2%aY5;qS+4bWTfB*yVsda`i6kR zM7|yFL!=>V<=Hnm`>}pMK>!){PK?t#>SpD93>pHW?Yl5olkH#Fsv9M!bF9?h?@mw7 znKs=_Wph+DJNFWAJFx3$Z~3?{z;MjfG=BHDCwk85@$ho16;K&hQcQ;wP*oHQy890} zZ}M7<+iw1CX^U2L`Kdi2>|TCZru5eTWP3{St-}8jA59FD3JMfFP zh`Y`>%6e&YVkUO$?CPm`hlTB|^}#r0OcEgqjX|14lTOavMAp)5(YKhOJPf;N4PHU-AhB%U$3aW-WP9569fC(Uq|Cxb*4A)es{k&wnE%Td-O- zQWM-KZ^M*$ZPSUaj!Iqr-0wJjx?8u3Og0RNKXF4C4ncQ z8ls>60x%Z=P>YhK;WCb2Ko&-B-Oum)}7%H*g@k!Of(>byDf;QbV1HlmBCBUCWY&H$<54{gv)Y>lGkRr)atjANO} z0*WE2g<2a>jZaXySgv_8dw%H5N`9cB*Q`r19hp3pG(cJD%iVhXYSoljGKAKAu)IBwwE_37oi;?C z{m5_a56Bs*?iq}&uef>#uqa1f7>QFRKXg-j}ih*+8OCUKV{tZQ*G zEVkza^0J;9S+q!4f9+Qc!Bx3}TIG$L0CteT%lq>{alUdu0@JfgZDl`O2Te~B*2yKm zAh-aRJ47fnJx9H<-tdE|L_Xga{m)@|BS2`zD>vSo3d9x$*uzn+U>0lSn#freV8_iH zpQ`hgU_O+9Yae)*=9I98dqYG0$Vd z*{o?b`#hb=ghpogVhbjkOPJf>L)qWY&nVg{F>vo6Y3kN(xtN+Y08KV@G;hz=5T2q@ z18Fa@E^YB1)pxj-D0IiB|~?AdnHv0ka(3O$lE z79*xnsD*W<;4ge~9)(i_MT%EeC=Q!2n>v{5>d`ou%<4cowX8jWK(W5 zcR8x8NLdv=17I~pgqvE~tnj=ig#r246!$o&@SX93{kFNj@}Z*H(jT7(A4iXR-YgPb zE|^YN1%LJ{Ak5a*{&)g{b&4?z!E2!_s(H1 zc=qiL6TIlL;wUD90_lzG>-lx-^xds!5LQ3Q&HZ7CK62Twk5_gE8K5bms?7-0kyI*v*0 ziaO4|*qSb*z$P_mhjw8?Dq*=jy6$RNN(N_*TX=L*3QWl%6au4KkUUS=77KH2;m~31 z&{nvE+LQjku{C5W_Jzv*l9urAQo&)@ROA`(iyZ3`u-o$jTqzS2HdB+|h`Q{3`&`1% z9GhGFjB}=cwx}lRX zv0m^(L&@0>7lUPVEAPq&}$gUoeXivP~e^yPG?izLz!&Obhn*V2%z1& zNZN9ntDPlg{eGr)1d$KG#t}l74&{jXL={?RI;?&9ERQYp-cKN#Cg;XKDmQblS1AfA zxvq-6WccWKx!S;NOz6P$h<#hPE{Yp1d1pSfY{g$B7Wb&H4J9q)mF zMgT|W_<@Dpx7NIo?)`Tb1juQh274;LVUDcPrDW1>u|q~LLoI}&7m$3XiR5%L+lN0t z$GCq1GzKeP&#b-62Y$8YC7L~%IY7IHAc%^)Hh)Z>yO*lco|gD_p{1^{|BI{q3Dw0{ zvA!C24gyhydn|W+M*qfVJ8m~k?1Kk>javwYFw@-dW?Q9$_Bp*W`)L{|*$})~I!bba z4qix9Fo3#V{$}AAz$YPyPO-1|9`v4H;#aPQm&OVi^^pVU3ae+1%l3NUK3lPiDR0pV zS?-3QVy%F6P5I*=*yKko;x|t=OGek2b$8IZOJ^vruxkt+`jH)fdZBgWzrHnH z8zt7VXS4YV2g0on|DuU&-!-t4e#o?(tkviOWx9T!#2+d4w58Ro{W4rCtd^f% zNI*Kv{-Mf;2x-UF;gwj8G0V914OrPu7Oafjr$I>?YdBVvfaYN#N@ETnATJ(wm9B#$FjUomXET^rSP@6gIj|! zDndMNv&y1l;=d$om#Y!aN0#qg=C@h3KSKY^mr1kPu0dt8OIP~h z`1mOx9+CdaK4#g(o_02Yws!jF^X2B9Z{-;v(ztU8YoD#-Qy1+%5U` z>SnMu>G0FO+mYAxOyDHc$HjUSxP0Epf#fd)^b0c|qh#{+4pG22B93$1L<7aw<31j% z9LI-6?M%PAW5lBky`X00$7u z-k0xD*Q1Z_eOAL?b2sm4xDY;Ngn+J9?oO7^aO_x63*YRA^rNVwV963&0T0Q6hm`e# zH9nng@!}qK!4A`m@@a9#=ToCXqg)z}8gjd_6jj8Fw!`-*n)^cfa71(h@4|`bFSCb9 zuME)rt}<0zhi#*qs2gfssr&|e?MiNZ#JZ7;wpWiDVkiWw03b6{UyDjlh@zTyP=q`| zm?Wc{s_!!E#}2kY-)g3F@gpxp{xbW~AN0s4t;4z~CVQSM>s&8{sSVSm6Th(tzJ+gG zpE$J;w+=WsZ3ikZc8GW4(RdX z++~)sy?Yo~vlJj-A3+*Ct49QzVi6F}N{d^)Y7Mh7$Z5)C*|~)o$TB>N$7Sb=y`VCr zM&E;C_hF5ozOW!Z$yK1o!eV9Y>w6qM7y>!@1+vom?8=PpOKr1^2@ZCn zHUb+B`KEUxkG^Mvt7i|RLQ@{LTzuO`MR~llMX+QIRht_}bT&APqff&t@Q?3QQ zAhcXahpd}gWXjdNHfs^Niyq7#l5?nkDXmaRt|IjpH$tH>e2`NqJkP+``zPh7nV!*g zv;U<=UCs0)dX**C*x@US_Sde`B-oTedC+nUGK}iha4wBYM}skwBNqxzo0tJ+f%v>r zIsv1UqSSyF?yhqWH&42JFtXHNn~Ah#7~Utrlz+;T{#$bV*8?MWAcayK?bNeX#R~eP z3jFKzXXx^>Xc*?P3;r%BC&l49VMp)|2afy5`ZFx?1PN!t6;$M&H#3j6Y3CfNyd8`B04>#WjtZn1-zX8sFWWZf1V0AHn!5# z#}DcCzJt6~MzJPEsw2vWSlv6*il*l}RO5pOZE5*g%4gyWF>AAFBt4U*Mr3|}`sya% z2xdyJZEBLlKA5<3%4063>-u%{(i7Mo++FsKO~n*`qlZ z_1sD?GfKcwXV#N7&7KhE@K+1!`f5Yz^4G^6U91Ucb9K%c&Fh=T)n7{(mOypz?(bGL3Z*F5z2^X1Kx zo3jX1PCO+^*N&3RP8L?(w};Z3)C3ge_@}q3>$2YJr-k9i56AHe9ELW8FC6XZ)@($M z8U`_wj+(MrQDVHKC_VdpDh;J9Jc|I_bdXvW%Bkykw3LTTza9WFb;#rGt^eGucVgS# z?)uJ#;c`80U8MlWbDRiIwa?wpHVEevm-Z=h_*PY{!u;3dS22QXG+j2NN(I(&u}Lvl zd#^(0L|flbPIz5jMo(`4jBj;H!q%iIph8cNINttfv=&-A))GHB`tD~|j<%<6>^7{i zRXpDoUs%)N%le?7*g3siP;P(VGlHPhY%8f$b*{sXn?rxRK?LVVY z$uCxwx3%ov&5K4xsZ z?T$&NjgTgB`cJ9S==!9(*&^UjK7stWV2X~^W)8_(1t+?hM;iU+TOM}2#R=DKDT=Y! z*~?q5!Hexy)fZK&n{X0Bo2w`o@h>`XaGLthp&$}<=0nL`0m{;S*rVZ@!bkEwqOPqF z)74*yyz-4qRHpn>{+HFx=xyH8Dh{pr*IgexOt06=usSVd1UGD6n-(ATaovZNA$HPp z;^~t}((cyMWyG9HtIaGaQsiAa@u?`+ohv=(vJ-spye{D{J{om8l}L zVD19dXqt8?+~aIs`{m##5uw>I0|x2P7&6PBXcd{GqU6F5sdU)LS}joHKd}YbiP3Jx zRC6mbKFcJEt}xQ6pM`22CzA~yKHb%uO{J!nkTPGiBO6+_L}caL&br<*Ep@eP-!{jW z@tYxZD*j{A2A{5dg>q{61KNt;)rm!^If9m0xNUQ5&YoN3QA9wzMwi;|ApIC1RP>q{ zFB+j^o3l_9uVjXeY-x|p+5Z}O{!(y_skwG6!$d!YC77K4btd?YLM;Eb|Ls?qX72B{ zA2o01s<$_=9a|YLW20_*wfaoQEqj5`D)u2qF7%*YHOgUFEk$Vp`3?yOfYULg^3SMH z7X%%ov2amJg#t4@HoqACRga%LYT$D;!Ww2ad|7d^4C?)S|1~*HYuGdnijN zKhf=BXI6{8oM2F}eKH31F>B&#i3~bCDNDE`*5wS_Ua;a@=0nhouo~VsymZo=>WgdM zF?kNXZpoZiPE`21ZA5pYP&Rup{u_GSYMo}CCj-R&hM{&20mR?!!|$_R%qDijRv$KE z(T$2e1SJp-p168vt=ao7xd`WUGF&vXHI8LO%^Z&x5NfO&V#Ihq?3% zThx)`%=@HkG;&wzQmpUc;ptY@Fq5}Yykj)}301Wl?PrrWE2Xt$X^HL2}*G8ai?@bmntT91B zyBF=iKufvGC6~y2scs{!=Jh7fiTOc(BKv_}@pZsMM_-*nH%kn^??~7z?-*B4u3PiQ zGP?Wf^xc>X>%Ss&RTLadp(_s$R79}u@~x_N#SIpmehqrIAbHl#^mF;4^=QCJ+%0W! z+`gE8*TK6rgIEP7_pEc8giF|^b-fKPyuuMFyka9_W~(sR)993#X zW$7A<^7;Ex)__ySs*coewXIKLO(?$RM1V2sn>N_Ooq7Cw+iJH z?MJ>>9@+kB6;}#=fr~q=c4<*;vH^#wgAxLh0p6d@36PmLGrZt=pB7=z|M1)9&#eth z0E3uw9HbC%%!;FpW6=Ww*eAZEbkbp!Z2%OLQ#A5T40XQYsCe;{NRdxUu>4d;Rs;ei z#Pj_1^K5y$3ci)^QVv*7@(t?H;P|HN|9Zmsw+b7p%1$z~l=nVvVv|y6CoyP9vCqKG zG~{J++tzM_!k=&-t_7rOqV%sEtn?Il-kzMF1pg|rQ`L=K>wq5C@tY#y2uEIh>_xC` z6;AdKIho#-AH`P29B#`^Zpdi{Y@hjR1#e|F3a(nafp7)58vGwr2Hg5cjD$?C9Mf85 zyL);VS?|Lo^>sBS5nm`k+uuhI2q87fBZi1ey{+XR2i=h6M`Z;KiW$9S{ zlSOG1r8M2U!J~exzPx5Fc%0`QE5%Mvy&k*SQpw3(51T1i}gsH%EA;c#SscFg=E&&4TylL<6kWb9^(>^}k zliweW9{;DAObTWZr9+)>rsA$7syJ`92lAikJTzP|gQ-hB|B2tuCxLm9o}d`quM|u%2#R;_veL*490vgb)6Vb=LjVF@=XVUG`itGX-TK?J?HKiLh73hd zSBR^&(s*cI9EJPCNyVRINzkCSdhjb1@V)Ol^$*a%#thy5R6+sIe1gv?U#U`rezJh$ zqqnY1QCPZ(cNZf4q1%9v?zM~-731m!VtUe0%#=jw13AE^0G>cnekI3-aK0uBc4d2% zf>D!0j|a*OFF-Ms_$2nnR8h~42}{wY^M($;VucA+Cm;;Bvm%pBLbXpBlj^oFHv92+lmJ2rCElKa+h+b0E2Z)}NULLqt#%SNIL|Zh{ zKE@F?UbD1DQ+RWlme+yI=jbNx#pTjXQ5jXF(ZmS=9sCDJu$UxF;wAWGtY^ry z!#zoQ{Z~8dim)HTY=bva-^J9}^euh+MiX6vkc&1u|9W>g@BAco<1Z2PF-^TEA`Ak4 zv%^}c1AXWL&vCkuF{>xH<&=RoU6bALqv(>(M#%yAP4XBZ8Qzz#%!mpnIYdJmhY)?b}i&f?WPp19Hn1}`^Pf)Njvr=FdypWE5; zYK`+_&Pj^{EC zXlJVF_rC}M_WI|CeRocVy!Ar4490dVT#_{8FN3`N_`#z{4kpGeyBe#GJ~=Ng)s{9t$E-9sRc6U1*qW7#f)Ve>z^jlZF4NtL*a;F_BI zpRB1t3XoPxOE9 zO)jZS?oBD=GERHZhvyUWnUC3Z{{cLSzvW=<&@a@We z$^VV!_g10~-88rV=<;=co1ooaE><|6!H*doj-_(k{n6BbKekAtdN3aR(>JrWcH-nE z=o0n^0y>)&0rYv#-(y(%oLd$0&9{O6#8r<3g zD4hEoS5RSc1sSoQ{OC{B#n@t2%uxtKJeHC4V^Q39 zKegXe9H&8HlSbvtu z5%ybnY(MzK=C3efwf^FL>`96JJNL!gAe#(1F+P*F+PAxIqPX^dcb?s}JpZ~>iKaSj zNmXsP)@RRvxO)uK*&eui%1;i(xPiaV!CV35b6rHMwZ8YbzAi=}dCY@1#2`?1Ept)} zh~z{3nQ(y<{HjzlbMvg1h)FOFy<5{~IY6J-gE>y3Si63&uw=^FqW;$Z zKl0H=^v%ah>~O@Y1Pel}@vEV6X2APb=wmG7*+|83cZ$v%V#HmfTZjXE4$zRlJb3l( z6C+pl?mks6$7`> ze+9{k)pEqZs|SXAr(&V3;G=C%RabXn3QsZFHh!GS3@_IvFBOo+%pdQhAR6K4YpYz3 zV*HT9g^x_L37Y5iSU%N#n&b>eu~f6T6haWnw9uP)$)i8$W0G+Egk<&@h0u<5*I>cf zG91KnC9}9JxF&#UdR+k2BkT=CH@~TP@Y_`Bu z?`FhHF+0i)b_tsj)H1Z0q&WweBwD@|K(KNw7%qnhkqSX^8L`nKc=lE{Gwh1FgZfN) zue|4`gpnLqpNVkf$YdUi92%(rRr_^pRF9S{Z7nUUE=pGxKhu6?RZW9by9l(NQf;88 zvrWGmw1+gfB&_r88mRG0YP9-X0UIH0*7AnZqxN`IqsV5db0EQBj?6(5_dUUHb$+JQ zUkg=X43Pz7IEhA+ot^M;7Y#G^D&5uHM?%qHx`_m<6{UrY36ez%d!b$9&aH+YKI*<# zG`p<+kW5Q~C!T?B>Z`_b@U--+-?+C|Fk9U($oX=V#lD{f3)^e08R^imA-WI?e#)w3 z&<>Cu8c>S=7T@uS4!HnR4N)MJ?~IhX_5361l8Y{RfSG7q30W)YCMuoKi`lQtB2v9b zrQp_H>g2uAoE9^^06|1 z|7*`hF%g&H}^mmhAF$w>niZYTlkJQ11jMRj|p2Q!YWyP0_woVX*BDVG*jG9P=B< z>=UowQ^VKF(}Q+`I+0HXHlm3Y`a_{Z^~nKRiWmyAJ?Em!3GErA0ZRq&>YSx`&aKG9}8{POtmqqjz_dmehkz_5BvA*DekGc$Z;D?$FenzYNO!Hu4 z7l~6fcn;$;cgT3uD+WMgNr?m&^qcjhNv;|Kk`31Up@0&lY3ay%&&*czhg2ObO2IgU zIaTMfU4FaiyYzt@T|TOXk3W7kS`Wecm>ND)pZa4XyKVOrVUc9-ERswJz_e>1j%eue z#%gv&2E-9QN4llEcJe*t2uMEG*{^?29%)R4+HZ8q2~0x>ZP&y@4s<7XMj}uSF1kQN*x_wVixlW*mY7W52_A8j2=6onvo|aM(KRxAO5;& zGPAX*>H3@GoSDAw^kG79T4?!X6Cd+;W3s}qjQ?Z@t+B;Un4%LABjsaaZ{q~4{^t!C zHB0M&etWb^bv4n4${`Hz2o|TEn~MO(kc^>jkNwPo?dt|qgRH}sj=IKnq3*iVEdxb{ zdE6-Om;u9EFDS1diBklj!<~Pp2 zDUzf_NS*)Gxn7>7q9~+^S5skWykX~<+@{x!CD+bq_^>sQmS5P%NlRK-FsCxi1?TG! z=WELIIDgu9M@qD;$zLzLe-iwb0oxo%^*I@Cz@>np8f-nX$$OnL<~edJaN;s&Wnc7G zwYRh%AkGkHZ6ImNQTKCxIsa$a=jZ;SZ&YRRv$nZU4hN$plHKv5O5+COFxUO`e>NJ5 zJ|3o7I+|-Sp`iWyeDv#-)p|_xkVpPJ^4m50n|$lXZwutVw@zi?4quc#*!h;%9pqtt z`~l-8sq~{tzqqsr`;+sG*Jy3)M@t+o!t&?n-tW?rz&6Tz9jE0q?B^arTb*EI!Sm&v z?>IJB`>YL>m0l>7ND5-%!{UV9T|{xIEC`Yq+U(q=#!?7vK4}zo`td9q<@ZW8jOCEa zp8yi?wwtfM7ix!lz?q_1lw9-U>gy3RuClOeyxh_JgaZYyGf7goKNIDhs#}fQ5HB8jsuAZvn`JBugWGUio<@jR^@jzC3)-II|@iViU~A<(lhycI=sf z50{nbZH0rf5=Dw=O$opG6%Y!{H>!TfMSADLcO4S>51|43N2^*>${((e&rf{05neA~ zXO2eLHNuUgLOBwwVVhT<+FG&wRC}F#apGnhkZnjt#6#`M?V9b`OfKS4BKeYQwG#OIsZz~(*@yT@Rxy}s+Z23X!23%CVrC*kG6Bp&y^BA zB@B|PO)ml|aEAg<>GC5f$JmA`uZTzzNojhL} zx*%`Yfb%7yt*jO)tqCVQu7zU%j34!o*Ef=HzM;&X)I}cGSLc6k^<+D4m-1W@yjH06 z6$d=MQ-Xc`$r1w<2_EvMi#ntD;-p3z3;C@v7Ku75;H{tJSonlm}8p{1s{ z8{{P(E5Pyce=Hgp)>=Ub4$xzS80l#39PqN1AU1)+PbpB<|g3!XYR51 z`5bg3gSZJUyzd#t8T4sp+B5~P*^G{O%mt86{v2x+lXtAa&2tdva z4p(~}o%z6`rUCxx&l*hl96#?LCH$RgRvzHEfl>6N8N8;=Oo^74&f!bdn4uiQY3r*#g=-da_mI% z9n0AYi+2SHW6y|a zE(X^BLwr2D->EdPrJuf{sdDTGA%fMoz$f^F!vv_NUsKO>5`#K7HwMuhJUf{&^H&)4 zNilK0tba8N%@``#|Jcugs?$zGZm%NICmSjrTIoVQ(m;vQ_TV%B8$^gQM=*;8f+bs| zoF`od@e*KQn1}3~g8d-KD`#PwM5K~NAD2j1OX-}gg*ONmVT3r7j%4`5AtapMJ6{n2 zrxE&YIIuglNU?@bYvHBjbB5{IZ_atpoZKov2cjdkmKBQ>*T%avK`bDKL%2lWiXgg`^Z*|*0dsL;n2mJ*7fOz!nEpah z&atVfA~xf|AB!rvwPnL`quZNndqlA5>ykEq3Fdg2s8X*9p_TDVZt`!F>u8~xy&Z*`+gJQb2}5i{Ph83_fI{To{TCb24hvnD8lvp`kqZSk5+s z_~jnNCIBo{Z?9GXYVgRNX9A9eLQ5$pi@CwRNcZ`=HnTpiBVpolfb?f2z9SYvfM;AlFLodEfYQqcRo%>C+DC(Qq2 z=LgtLNJDXuMWDJ+GKh4rkU4V;7+^M-?o?knFzf@J3k#;x}MQCal$6( ziwdrVosT({e+CH66{iXa)v-$<4pT$s2E|s<^I^dCATQN!XJ{b{NIqD{-&#tS%cssF zjE4SsV*E5&_x*OnKL=VuksNfVW}Z1`|hjtSEk&ADmMc9ANTp8xIoE zGFc1#uome zBA zjv(Z1uJ;l1rUrfEu5p3SUHpvOIO5nZjFGg1YwEPwBmer9KQ8A$x;V-$&#-1)v>%hk z=}w1*$hC>HJ$5_F<7BjvYqgK!xQ85$Zst-r1^#xQ7qF6Andik%Ps`+BS<>N@qpG*f zRwR-}>RA1hi6*W*WOnOCCvhMUB9yX>Gq_}D0mo-*>m@znTPutQXbS+1JsO$Y@MHTn zP*e_GQyT(}!i=#1lW6plv1Mlj`VTR}DqSS{K-?%M>5mkCJ`0h8!|LXN`e8;7Qyz-; zepZ)opa%-fa74=mseyRMB}3|qe>5Xog*(@UAni3sf$MwJ_BlZgWaHZJv#Y3&6EMVx ztM%Ih@d%bufv=F*RVkTLGgI2)1L7d#v^QeQS4OJZ68Z7`fXrE?d#PQ;l0NR{T`uJQ z=X2)2Ki_rpZA#i!5LvU)e*>8y^C5OI(7~N3qlBX_kk=Z3=8a3PK@i||fJckm+Q4IJ zk;p5#k3LoRqY7Q7g+0TRy7#5)q0k}{r9;&Gp9ZZ;x)GxIy_sxe2XLU-6K%8 zL1m(%LA9*jox5$UX)KGR_08I+g&p3|E|#z{w8R^=@#y^l3N5cju7>^|D{fDkh~l>D z-6fd4$u2BfA^vc?&&$6)lMaUw#!yY$Vp!}2Ua>^ZODc?E00mvY&&M?NXudLESG(Jb z(40lDVyT}8+@R% zu3MkKt1w2SV6>yCmmlwIdq~knjuU9d(~$Fv6rJ$NyyFHqV)ivn}`1nV?3} zcu$ha#;}z6F&WZvqm8hPORjw~*}-H%eI|u?2kEXn zR~JAP{aNT=<7XaM*wMzJ8E|>Zp0nmSD#j9+7Dg13;AKc?O=etT{$*2@_3B z9`BYOwOjXY4#aSuV6&j>#m$+7)*jL(1nMZ^2HMd4C!x^Q^EX}G0(#lYo@zqSV3Sb8 zmQIO#OURB;P4Yv2_?_i>bT}?D>caYvNe7BC?O>G!RH1-DA_#Tkj6~S2W+pze<>)Fd zhbk)X4|(-4lXqrmEuZj{Txn_W@^m*Zh1D;MknwFl+z+Ga!%2^zv@k5Z;eA9C1hWr6 zR^P=nQSGdNy%EyN9~escN=D0DOq1s3C8fj#D#Kl!LmI|e?RGh(0vH#@a=%^zEpVv1 zJP>%K=zCi9h+D4JJal}Qj_L+>JSHNjOVBfdXtk-1Kp_CGFRu3hk#@l2mIvL7^9sUZ z=y4*RO(WQuUr}q<0I{-yl&C?>Y=Zj57f!%77AOII2Wp`}MQ;Kil_+FgLALcQH!rVy z!%x@ram&N|9Rym$9JXGuxb9L(rt5z@tby0%)R3GPxiTy11Hda2Xl0f^GEwJHpgGHV zHRCPQUx_<3ju88N$BODbpQ=`2s1_xJY4&oM?{9m0nwxJl-chdCncHCkyEj$eKI-wLA!k*=TyOxgq>U+i0MmtGU`xs{^7i^sfu0K~oNCwiez@@kK}WI2|qC z;ES*o#wh=G-R_K0Z^Ma=*@(7wm7}>wVptLmV7ez67s-R*bGuw*dAeYm-hTrWfKbsB z{%Z|K6XQwyCN6r8%8V?6BlTeqDfmO65~BIwHhtS>L-G(3s!G~!+dgi2-5V82_9~ku zmfz0FHUh$+FNX_e*1%yNy+(>_8_~v)KWlaIdH;k|31>T_yuR2XTEvexdf_T;JE8hV4hA% zKZv1)>&t?#&rK^zjVQQDzkR*b6hRiRdclm^8+!ab9XW>iIRiBE_q;j!FvPWdKk=)Cvo862Is%DBV%I#Q&X+=<9MCoA*^ z3gK;2zz4JUW+B2euU36im%0mex$1}Aju;&QIIi;HKlqOIZo>nXh)0!Q2 zz|J%zEhXvvu5CN+&k_9DT=g+;z-xAQG=5Luh9GD*P10>ok@5Xb<@mu7IXP*(4C)~DWTr{30*ex0oEm7wUD0jcl=JgPhey~Dv8odUN4>7e z9GJWui=<9RLA4HNk;7C`p{ z3k}lv%0hm#-8esut(C>KU^@!T=8`jy4Zxiqd}?AOc#I=}6|=$n(_1~fgx>E|0WrTHXMmt&^uObYyuSazsR~sC3 zcVas`JBPi>`bFI!}9*@cRb896c|JNw8k;~XQ|JA0D|ku6*1LAH)j z*&O7^7FpSQeV>Q-=Xd@7_+H=Z>Uv-A9G%zm_1w?L^ZvNqnL#jUu-3r@4$jWiiGFCw zU6SA-!gl_k?PEJH<<+;r!hF|>;0m-To}u9ui1o2XHCy{({K5-6T$n&%qcxQ zzpCk8!LZ7I->V3Oe78d7m9v-e)UAvuws0%&eW_9e9wxAdCG2A&#gw(+pvm{%I+2y) z4g{DOm@6qFX-fG-rVFh8>t$NNMT~8@Vw6qOP2*KukKJe0s#^~^rK5#b084+*baEkP zmm~_@KqUg>PF}>$D@~uD9D}j#w=Gn$2$es4Um%s5GYR#hOS6Nm_ZdT@sN;5=u5Zmlx#u2dPYoUm2r* z3#2|(ln@zLmq^sI)aW+8GBAAjaP4tt*9M@8m;PZn6*){Zb=+F%^Qkd4IyRp*WqXop zL(_arVV70G)GJZvBP7oEP36R~OF^cj=VgW(R9`f&ne}jZ zm0z>mBHkql<4N&Y7u57Iee=T`Xp3LG+Z)X`dSQ{ z>IIIBVsY=cmFvxJ;&rhrO?$`zFXNgAbr#sAgudLD*X}Y*{NVn@>#menvp&#DV3ZHg z$PjFN5`9%w)#_0S%#n;>k1*1K4>3pfHxF&Ejh9*YRMOuoZ;El)r>#k6Sj_Qceqxla7r5=pe9uJ}to3*T6pA-4ps^WlaC@Wf%gc(=AYjG-aRjE)BO z53`N&4}piUYkZ8`v}ix9XL(RtAuQxu1AxuOk_jBYHi7X9O}iSeWOUNUSUL7A8)y_~ zL;K@9>LcPa@yK)=%iaMegb-R2PO!SYe+kfAqnOM_UU3xEaO7K*_;aG>?e?~zuU`Jc zoOg@jli4Wa@kasz@NVG$;Xn}(%;oyxiAwh>#wl{qJ#7S(y=t0I0PUm&R%^CL1Jwhl z*+&ml)+>j9F?$`H2fC{6+Qptv8jHF-ah6eC)s^sDb_x!{z08(h*mEVNmJq5`?4&T? z2M)Vc!={DyPKFOx>eCgde|kU2^LA(KZ!OF-XqqkvNH9Ea2Br2wm<=N*0>dbbj^?X(qzie^*0HOx zUa%MuOvl+GO@e6~qDcgM>sTZ(Rq>AJG!^gqdMQ|QVYn&8=KDwILue{9+NQs-H;G?TAhmU=!UL++4;{%nFB^wIGL{wC4G~zG_a}Pnk&ibuv}q9-THF;Zlb7*cd;6F!35- z_7r~)$k})a#@YHI#H!c_8`J9WBg?^K(REHHL)Ve6y-}j8L$X|0p%(izEIlDufDopJ zTrc-O*D^~*SCAL1m#D56f@qdv*6U2A028)Q+8;fiS4)VvdWzjOckAX{SLdW2TThBD zIl?i{(nN-?1I){F(Th!^@qCSzEsdM(!zS*Mevf(?e8wKa|2P?1lWq_*KmG*+p$%aN zxkp&a`JZVq1Bk0V^pRFKr@v^^cIL>g@u^_*`Fz@e9l7Mjcp5Mezj?K2wf{|{@E~mK z&ZaHEGE~R5Fe{0GOFB@8+2&^m-vbjAqyJW%p2IKLSYo+WNc{Ou0A4Y0gMMZ(4f5GD zjhuERVhg#kmc!GBJ%HLs^4t_v^ICtDJlM%Z#k9UCZ+|b})5+xfT8`At%b$;ij zdNsRt7Y#<{79`%Pq=BJ5Fo+ywz2}f?fRtq}OM|_Hwd!U>#?y^mdlNn%%g&`gMWmMr+Fdz@Z1f=(SgPspk%~Mq}+K?Q@hxHx~~76FQPH7Jtqh4 zT>8$64=YwmlK|&roQs5o(;eT5QY8a2`4<_W(HpAj?UIGK&@fm~AQY#Tk;{qCBBW_e zzQI_ovBzFu@arK@LR?Y`7g#)6yDSuwBv6Q1hozJ*Q!7Tkw1WQ<7 zlE;%$!iZ81vsm!Mo`Dks>8jZ5y;ZoLTEy?rEF&Q~p^yejOhi-^v&OKIb$Y}1K0{XU z`HEfSO7J`_ol1Kryn53{=V(yZ#saqzf}h#fFXu(X>Fp+wi!;nkEdvu`-Dk6Dmx(L% zyK7I6TCK(cLrFACSab3DASwk+AYk}eBd!idSYeG{c%5Js88Wp~>C(o;2u^;`=k7}( z;NZnBSDFI6D zRH+~;ip==}c{$r=(O$JrhsNLe=x0oykI)RpiY87lKaEB|pkGfJaqaU=wJbr_*;OkM zJ26y8FS-uB-I?ixJ!#~fd-p>m^XX0_&`{s@JF%*o@OL_{Gew|->wUA$B2DAc#jmZOFRSH;O%g7-2ilL>%?)!+zny}7?&tS7i6;;Ttm_2iLtPXEGh_~RIP5BvZ0=d6_dBIV4 z;vEd`0Z<_FAGCY|IQuSbozPQ%{RpRhE@~-3!wy{WI@@3GTCyU+jp55ula}<+qWM3s zP-k1#c?{}U%qP&!8-1dPeKU~5ko%5I7+2>Bn}ha_S#s1Jm9I~33d!xVBptDc3lTUT z@+0g7)jQ`n3-9xS2-_eQj4%96^CTqTK^UO>mOTn@z=Z$x z=zKu9=|A!><`5=+p(OuMRSYDZ>}P8sed#2 zx%>Y?BX1;g`_Q#lpdANp7gR7UgUxXrM>d%h2<*Mh)Cs=dem4r2#{oO9{GKgaWd#dy zKuSj~O`X(v1GxGvmz@>LuohX7lE&k;WU#kS1F-^thfHTwEPnQOSkD|RD;-};juVh z;yVA{Dv0j1W)er7X5WRBG=ozN>pKk{`G;K<+<3+~!bB!hp}4}xqm_bykD6nS#6fW^ zM6moF5YMBggHvDF=WzZ@VNsErN1Qom14v5aiZz{0-X@i1fq3%W!SK=(S55AW68(cB z-ku;^R!9ltt;YIT8B3{7*AFlxHoRLNdw9p25AuLQpn8$Sv%Acw zA#wEH55s6@;f2o$_U)na{ha~2xAX=Ajr3S*AdNx>t9xr^tBYfiOPPV3ZdH~ZCvRpJ zkO9Pg2m8&~HDS&3;hYhLY798S91x!A|Ass3F%Hwo<>5`S(|5 z7&r0}yHy~K1qUb*^JpI#A{ozRq%2EG%S#819g>B8(gt7<6cFivgsM>z#on2aTn z**j+0g+m_zO|*!-phX1W_=kKmE>^8Fr`_@AQ^h5QiOLg8NHpj{^)!zIj7~k&&J> zoj||u{_l{M3(YZvrL{v+7)R21f=_}rR}aJAGV7@6u4i4_Z8w8284jNCiw>Ak#J@Nj z9%PAi$>lg)#9S4o&`*YXtlJ(+)jE`;A>NrCXHm!fin=(MDzm$)vKg5Sa>0_P>63Es zBRtu<;EyZy>KWTC>E)S%&v+vXCL;S#22WwRIoJ7eMN=k2hbT@p!9l<-*k!PGR~2o| z`iv!S_=}Om>UR!90|0ZFtas>Tyc3ua2^Gs;{{20U!>063Jt>mqJxnXeWN%D$)I-Ze zs3uZ@OZ5!G7nbQ_nt0i}Q?E{^Gf$Wyu_0zV4H8&>(Dk9uM8V(UE~KJWA~F(p?_`a;cXv1cg#Gk>Q9Kp1qfM0z@^cIm1^?W9`5us zTQmowtRAZ=r)<7JoeoO~+B*NFe6RGtmb_`^>t?*#a!ziY3rr|ZNBU-a=qsYjqfA9s zjYl5^dtUMIY1`EM0&n=5XbHxpcaTo(2xuIJQY88x_>Ryt77e&mYEGxYiRP&Vjmt57 zQ-s}o>S*)i2gF^k)afb_$p$3!>`4y7dK=oHfKEt)DdO)Ix`s;n;RgrRNpod*+&9S- zZX?}WK<-u~HI0T8L3)VnA-3BKKWgZjZF}q#D%QFNcwY8>dX!M*_Q`m;h!jX^2!-aK zIK{+~Ha-&=449TXi$1-vTEY(Dk+^DWE@#J{)yEY0;=JO~#8@bPab|O=HDpeRSa3WZ zU$*2)qu*4K8;OXW(2Zrc^XCRM+5^SjBSku{bnL%wTbl`f@$K>4n0#ZWoUfJ^#R0>4 z)wNiw+*R+`iq)`~+UAJTRLQk@YWL)1y3_6`JzWyE(h-`42c@<#Ys*zO<}wa&c(P>E zsBp3B=W9>ZX=eM~!G3GRY;adx&*xXW9xVermoH<|`ex&qJX9HPPgKxH{yQV+7yg%# zs6!drA1mTW#}$#`f?GC}sGJR`rFz?aZTtWO>VeRyqfi%M>MPNB@%clHuvCF$^Qp31 zV$j-!{D*Zw*o#Nw+h%$2oSv;d}uVY)65}fe+95!?^oq+!A zZSgS2QkxP*>??aNNeg$ORkLfW3Og*{{qOLAwFmtLn85ILua^%?A0ZL_HPOy26A97{ zuXN=48851tV*87%TmA+mjaLj9+_5GP$OWWArp6!vDzDuL$cLdJb z?yGB-2wESM+yK^(`-3!sfJrt5J#kfj8pyB;OLID7DHXp|R&m_hGM%!!(9Ijf4=d4hD(%7-cGf@bv4Uu&K+=4Y z(c_!6f+irsobxAF%O=!sdI}yX^*ZtC;cKu(@~n_|G)-7!@U)Vlb~$!1g%PdSw3wXs zywxv_uF=bVC$Tf?(DIyO*qCnE%2-JeOjTtzqit5thD)sMEvjjrIW6PP(oq9v9ql45k)t#qMF(NtTCeyQrQGIE2BI5N9* zukgahrVz>Q{j0?8zFo$nKNT$#h{1+~u7S+QYy&jueoIP*^W-RuL9)z`K#NFHWj=Yc zTR|uN;`6dQ=kV))v?$t(p8P4-la7uFYOOYk79{k@pWoL01LKm{X-wTG3Lt<9I!rq! z@(GlVK6}~$5-Rmn9t7?Wb3To9jkZUOCzs%+dDUUZ4%3y$cuF&x?IzPg-&?VCvcnhh zc3q8SRUK!0VN`8;d|p3~kLEsq-doM^frY5~U1ea4r6)zg+-?{)_ZsikTcgy5Oh-w^Z z6k|TwqBtrzd2{{=@9)yjRk0e-z0KkCPu$5+QPT`C0uusLx-O?%{NeDux<;ePP|aZB zFd2<`t!0OQ?m?rl{^C_v{hLI_SqStNFe5*t7;ZWD6Xc*B=1kmpVM2jq5_c}JwhFZg z+*1?3hIoWg>@iiN6s;JKb|&6eAC+@!PN-U4Kdrc!Rred0Aue`B{#;sz+6Kj*v=j2? zv5V5f@-T*lF3Z@;>nVR{51P!o{1$giB5XrCs#{wQMAILfxDpu9bkytbvll!{#}!We zPFi5D-y0cRm98f&9lcJsj1%Inb2%h}P>xTqZVXgsM|gtZ$t=1vQI$B`e4+LqB8f++ zBFH*jFi(tR2bir}^08%`@f0|$nH;xhJtGq9QI@TZtbeY{}M%KsukJW4w&cS0C#VbUCH9>l}Jmy_7Oj)W0L7H2di-;}<& zxy0oAl(vJj0g!%l4;~GdC>@m5U~C{G*N64&E1F%}6jvLi$`E}S`{t4B<=mF~DwKN7 zweyvj3eR78mpNW^II3AZD=6fI16|*7sipRAa3=&yWo!FNjdb} zH&}-uRUF$)AZvmu`>!7Z6E==K4E3xSnf2r2cYRG& z8QB;GeQ(J^lUPD@Uq~A6XRgV5QZamTI*_uDqFE(E`r4#{~M>BR62$_i8L@b5My6YHBWrZUWk0)$+q#H{Bi~~ieKvg zY{osJ;ou!*{*#oa1jC<%8wi&9{MOOn`mxX(c~_gT)6ylSN%K1idx7C|QdJ0lma?wn zYI(r~UlL@B-F~#lZgfV#&A{hDV-E-zIEd26EQtVNTN@6a;|&-hO(8Uk1bDdyMal+ z`>@?}FL)JPyl9Q7__>z?m-CTS;dXg_at8TmzD@xqNzZCY3WbfSrghiv$&JDC!oy`I zQpFC_&DFYuL@QptCpaCqBd7D2l3!SQ&p(DzRt6BPB%;uv9fU;1lq}unOMbN^kz_-^ zH3xeETBdO_j(pbSbmQS_#GP1#A~JD=B=RZW{qsd*a0mIl^1Dul$m`V?f8{lH#P^q+ zy;b%eqsqhUaD{V5wTmZM-y58Qamq?EK^LDH;*Q7DGxB)%v@+;&zk!l;Y|i~EDOCH> zQeQDuoHtuiXvo}T7}AK7C+7SOZf#u-pw`wzud0hDK+=%i9$t!P0<2K7I!D(^{zdIe zqK?k~OOI!<+X<;Z<*onYMT19$gFl>XZ$se=029 zJ26sM;O^G8p`3lZ>AzwpBoIdwxpFs&=kqW3u&SzAj4dNx$=w(R_FR18o1%cmTg_Rp za1@J2RMHp*dpowVvG~A&?d=&l;SOVIzt8e6jqHZ1Z{;9E`Apl8r>;0pQHzUK{6%=% zPz;z+pI=5BSJFXD^OdU4UwSB|_WqPq(d{DA<|FZrdSo_(t{vL3#o0(8O6G_EBAemC zdbV(uuHt&NpvQq3Po;R-&zb@S6B0TCwAtWGDJH?m;|yg#3ss*(k9k)i(nl9Xj)niq zf1Q2&DW&E?g;F{xuR{whX+mf&)r?th8%xrTW_AH(6Vz~mp$MaQEc!hiS)rYvZrd5UaPtA89YAvB~jX-XD?!}C&4p{4t;c%=Rt{bJmIH7 zkaaxv3@uC(8iP7{CI&QWAIyvW3;SEG&dmKn87MCN{~mSQj81rUH+j#0Ly^Zxuok7! ze(e=5+i@k^lY3zN2*^;Vza5_~B@HC5{65~fLp{e(1CAlp2ns&FETI5eN?3XD-&V11 z2cZU1`8!lfKSM{}t3#kPrU%rMW-G}EyUz|Ri&i1>Wg-}cSo_hc?e$Uzr4j;i)Y*97zT^H{Ap~i83!-wip6*E3gWUM8Z6oikFH$b=NXN}0oioaJn?RYf z(59j3Z8#SHEfxsRa7n4UNPC2m!+|qVWU%<36~~!%bL`#KXLz3AeV`IZ@RAG zrh1c5+}F9!mHdGtHy%%D`s&DrcKAVN+i9}JqFh#wd<^AG+$LRg$G#XXE1rXhe~gjw zdFg|xnRBm4gs^IfjgjIcA6}az0gp{H4{Mfn+{+_l0AAi!X%g*w7LAvtMaiQ!%wst+ zFOa_#@C&W{!_|ucVkLDH=R>Dm!`dQ|4F5`R=<+wu39o84OAQX6nN4YEWFogXPrB%? zs4Mf%Qh)x7Zs(1uN%51lDjQxpWAEg1;j9CwgP->50o@j zAnnFs9Z-Y!ibW4ZQAKk_N(n{);+fl`poQ; zEKW{b(v{*4D-EoUBZ-(MiR8Et8lw?QMs*Vvu=-yMCc7EAf<&2Zn)*&OG$67g&{?99aE;7Xdo&XKQunL-_q?6a8p~b(+@3QbZO#X z&smJL%TtRo$bJ0}=pArqSJs1Z@@Jn4om@w5tTPdtcanEedy3-^9-Qv;gLh~ku>A+8?9u(K$I;yspg-I*nhfLnb`aG zwZ^~R5B*zUYin5tUQWMK=S=#zkLIXORNwq0d9Wg7ts3_J@d-cQUr?N9Yf^HI zl5g{vZ0I})%IyA?hp}yyPk}f$n&D=F3%DaG6n>rQgujIye8IVLroDbh9lE|Q?(3sZ zgNryUUo*c_Y~%BDdx5x;H7{h~HoJWY2@`C6I-_R*>Ot#|z(R~UA|_QBh<9{1dW+w) z-epO2)zB)9Z2eN)%TC5Fep3dD%S1C#Z6gcc3h0Z(K*|v8*4U-fQopbrG_Ybpz~6uZ zWwT@U`;+V@$>oJl0O{sH<5vmvaAlVb!^@ALacvU9s;fW_WxXE^;?SQ?*c zq``Sv2EKKjrN(=h0jkUe-mfTkSmKuW4@m;s+~C)v{@+J~UDN$J!8Vlx2dByXRqH$fuEN)rnY-3e!3-9|BQnaK|*KsQMg#@-S{RvCnd2ZS7!FBFP~>tEf$dAZT$^?^DpS}J_%*2o~Isq+H_nFI5<7`{zeAQ9;pa_GIL~juLf?E@NY*3${rDr z$JHb~-`Sha)7TA4GuBhYFW3wBdPCnBbS~yVT}o(^XB;HVd7GS#i7C0v6jh+P&+ni) zd%M7;J@n(?gfh{;cRVB{e>mibnVT7x9;?Cst))8_PVO7n;oqE(3Au&uSn|a}qV;?x z&G2MG*>--tQ9a=s6qdWAny_BR)@O+^tPbLt?FxMrejApXI^{c!(f-j`&hg!^ZLr60 z^f~k?(}<#1%U}B3S!Lv^{zs$mJL8tx-;?6JfUWlq%}17)ix4WxPni~cW5uKvO8Nb- zty7NP)ov~De#%RKm31XB67ZjD83`#gujn>6Sl9UO*eK-k1ci&Jms(;1sp|h?V>91r z@MU&2P5*esKPq4>Go&ES;=W~Oka-l?6h5LT`|^SBxhm8t6!&hTRL0hOrcuq|9`~P* zI|XVgxEFVcNB4G)epKJ2UT(YrlQQ+T?QtSY;N}!8ZH1xKbbZ;j8_i?KXRrrXK`L@888J6s&JXHf5W0%m9 zu&E@hYCFjlBmWwYj~S({=KET>gG!o9rzJx-*fw5)CFG-lTk{1;>1TYMcjtTKqR&>< z^30*3j?su44qCI-_P5yz=%ZfwETy^WrrGj5kmiM`@JnAk!D344b@?J6XJH)8rx}sp zW1{ajck45zQBUA9Q-ugp_TAlOwe&W*a>(lF+G7@y4S{%glgLy_#K zN^;ZCgTVV4PQF`SxJ=(5&VDQt3%EKgxBnmk%l}D8OSf3^Ej%W&P!c8(4P}L>Y+_&C zR7V(;!*bTCF!0F^IoUC4B#<~HBJ7qVTpuCBNDdQNXzBVQOjMrZtpMUs}J!CP@(Ql*}L=XYZ9nR4YmY>#k_QtO#GrwR`8d^tGGH}MAt zDYHJV_h?NQntXm7F%)StfL5Zqzre%?v7IX>T3=+6Ib(;Ygi&6?s)BB9{Vu*J_dI`- zvhL2WQ-o3+V@ZB@jgKk8f6$FL=a;QNAwBxRnnO!6RO%2L-tT`HIzTbxzk=*b7uAI2 zu9AWG8oH|J1v13E+;FPbn)K@Ir!OhnuS?dugI*dmnZcF3Pd%i4CAv)?;(a-a+pjvp z&*;-(7U4B+eE&j-ep)W43H)hbq>o%lK=Vy9_-D~ z)cEW9Rf%;p;ofK5lOKBr23jnhoI7fChzIvan_#5ZJ7q;HvO@6q)~fgA)Fpt&JX+jo z#JadQU`5u7aQr2zb3ATTvCIFEf6GkTpDyGgWx!pkgTN;ArQ>TLu~s;ozDK!e!o{qy z*79a7k}6(m0FNT$rWK!8AA_KU{Bo7u^Zlmcf0gj!P4*6c)iQg($UYTCtOSS0f-1>N z@?m(y7r|0uGtKM8CF&0#(kd2WN2#D2xNiE zV;<@8_VSTgc!1*iGBPQScoA4t>H>ufAZGnHp(cYXZi7;mQ-9&JJ!&crAkSvHEDDz* z4Tiw4p5KgZrj1_6Ytsp2_xna&R1z&al^%We1>w<`^7AVCyA4=US{E6u*rI1yUP?# z%{llRB|L@zb&h=OV0FGg(7)$S6 zqxo3E;5!nNtPcLjyu7+W;=^DqBIg9_y*s&+i^t2IybLg##ot$D!pU;Ix~o?={RKQ< zpayo3ea+QU0Ms!bFPGz@%3jS)8_R z_?c0)IMT;>%(PwymaPA^G6|5eUH^!2`k_HwGJqN#89OWN$G)WbNdH&#cejDg^-~{i z6=dXGEN4J<=rwb6bhNX<|2`(Jxkn;>5Jrs6TC^k(@RlR%&ZZ}s^{k}gj9KH>|Gwoup zgMa%S;2+EVxb(TiH07(ScZ7$;)48D|XJ7C$*MRobHnmneOazXj8o)_1fR*ZU(`&&C z{43LM{J#A1s(;{XtdmUKlxtbtL$A8XH&bpNeUG z;3N&0U`mW?cHj;X1CAhQGidQ`TGygcH8!lIjFB3Q0dcfUZSa9i6PD_&8$Y}9K(32# zTQZLQ5C&he{}q%Z2)Fs=V%=xz0EUn{j##mwFHMP-nD5#nx?%!an~2q^yJ3>+F%ZL2 z&{r_j4%S0_!8YHyI!b7m%}9vJrkA1f!Qa8aeGGGHCH$)EUC&mA{Vl0L zxOKeGPPY|$nG4v}VKNE9POR+!@Zt(h7rw{2u9qv#aN1!2cq70X3@`!6a5kJ*M|;J0 zqM8-9)-1c2oj&oFFfuaUs0iz2k6_^M=B%n@6@*q@<}AtTQ8fIP7EK?xPCM+H6=!+N%6 zlJHR;@d(gV?`W^Y2;}E4VITpO(bBQxO+9#Lkxgn0fRQ^2`3t+Yqy~MSvb19Q&X8vPS?r(`aH2|5ESpdVAl@5$x zWA-XynO{-WAs+S&5YS3^?plj0W4cJ`)nMs2rNy-OfYQU(WkAJ}ogu;?27isB)x^%_ zPEJ7pN8Jj;8_kUl$RNT0Gyf4xSq4_lM^TvCpFSOGF$DMy4D&CGxs5m^*}3Dk<*>P6 z7cW9yn6q2_^~|-jubBFzxoU5|@(II8E(UpfjZ1dn5>W$SQ&=#>vo$ql0xh*aDS!Ac zAv9lqOCQ9fkN~r)(c(^n^L7_)vS)2C2J=@ZUDD-875XXQY?ZKUqT6KeB1WLpzV^jF zN5d#c);Y#L6UTJY9Cy_!pC-8aM8A?0+2yjf`2)mjynzJlbn98p_dWRc;`PC&A4Zd= z9{0p(4cE~RJv)(;F5u&L=1ljAH|-7JP2P=i0qC!N;qUyJpivQ@XCi@&`!EkA_$K{z z5nKr5WEq+JL_BX1T1N$vRteINz?c$>7~!G+a(#@QQWwkvsF(m2P-&E57y!j365)+% z2-G@WvC}3QM>r(__=1Ogy!Fcco^$~zr+T_AlUI+Uf`5t*&qd0_KK+z|w&s#JFf@r9|AE7{w7W9W{SReDk>eo{ zRTv!(<3F)*auPJcG#wf3WoVW1#>?T|ndnPMSRbQAZguneIpdmGS&pZ+-~s}evt#C@ zZJdzr?Sl3cSsvA?zAi~VO=%Ktd6#sPcImb;Oj$bK-%&2XfIq3~>W$n-$JS}v3p38N z3p*L|@@3;mQP3PaVY%Ao$shj!AE_AVlQDy4fsi;ZyyBDUoM4%&?t!mv(gUL_8js^O zO!wy!BC8-hJ*Nd_n`rMoP6`rIq3(H1g0Lr>fic_TIktEoy}2x1E6~u}nV3?fd5FBg zYz4^pa7`EiMMubbDRfN*Yb-KLf#C$nTBH-#JOA8^dc<%^wH$+rW7$-(xZx20x2O1$ zm;gjhfS3T<#Zl9}3&i8YgD`N?DoT-NOAYdfYER>Ld|KF`<7m!>aS_I2n(T4&(9t zVDK4j{vl%8Q30eo*1XyKrbxcSCO|^GxfDf`9PsYdgZjVhC-lFoZ74fXc%K4UwR1Go zK<=m9jY_*ulB3*jTy{9#4~C%OP?6j&p=B^jk^W0HqewHpgjSv)^PlIm|B4d03nLra zWGYu@o^DI#R1HyrgPccc0G`D1gCT9K5a6E1rZ=ry9FH@@}ae&nBem(?|~64_Qq&yaaGZ%vN1JCejU z9!$$c;YPVc*f_#G+{Q7nLUp9xymhqRK4D94rJjD*YqAIlM6u0wPw5sSPwpAsADBq+rTNoGKbTm+W~Y#$%pUD-77IahLZz%+(vWrP zMFU*|2JWjzg)_~o2gZ_5&wfQQmwlP9t22HJ*LD1%mrrGW<$i*HbR;+SXj|t6+{Tgz8J@p<+s(_ z6Nf%>7}9IOfE*rC6g7SuscNEK%mCZ=rs z8}O0K!~e)mJ=zB>KvM3ys-QGgTqWE`LDeFEHqFH@Kwup}#^|(7%0m2yMS@g?KNk$j zt>3FDMwEcsODT((fVA4Qz@D&rmg2f$cj@7l5T4zd?E6^Drk=k@Wq+bai8{>5_Pt~J zyHArAh2b#D0@l#4>GNS8fu@Naj84oh@U?F0weokv@=WufR*u-yQ}41iu}DXwUw`qJkN$G+ zFFk<{m%zGnDREyk?%i6hMJJuuQgiXAIy|d>;&j3e!Y0EW0*YNGIM@EMun;Y+SC@hI zEDnISxT$5EfY$tT8z65=X87S7htZk~o&pHMFvBHzzL3WljOh?zNL{-i49p9vO!r6u z#!1LV@KZ4v)5;lYqqIJTlS1Drjwmk5g+Mgudj2fb)WuKBGc)gcBa5ihK%2;j{-@$> z8uR|!YkNLsQCj-J@M%XLoi#6N)U~A$_ZRsop~s=vTi+>{QF(XOmO5C~g;^jpk>->< zHAlXMU9BQ6Cb?~{`K#0`p)!vEo{jQ8S-Dt((u}U)8h&7bh}{9aU!`fZPaVV({H=Bp zXWba(^I5uwG(1e!cBz-Agg22rW#pAyV z)2sDUm8GIP(bbbLr&mYiEjcKI5(a?Ap;%&b3veG3CMW?a zv(04ZJ7yP0M|LhLkCdnmp_GVr0ea$X87>vD!OYsH@_qw)b$jcQstPXH&el8jRx!u2 z?U0e~NYEf)$qY?ELV_9gD6HKwx;Otu6b5Y`K0X*x*myEbl1n81K-dkY9gB2?)n~f? zb9+!7ijN5w3`w`OfK!nYmG@#h4lgHW`X&e3*<^7Vgch?etT;{`q%LEQiAvu%u6+b+ z=V=(!{@e_$+gqMtlc&(0b0)H_&|sU6exa_{`!4n!guf(hc)(S&RkrzSv^*27qg&pK zy4P7gc6nK6?{Pl3=55vEW-$bBV^&&C*MGllq})0E;SYO~!**@eEHp2QF5I5kG)Am+ zj$2?D-nU89B~`xKQKYGb_^_6!PG|@Il7|k9h|ZJ5dajGqPP#sf;?B-%{OgMk8G%vy?l~!;>F?Hyu0&^~gHhVw9uxnA{yX6a6goA7T zR=f-22V{%%r{&SO2=R$@aZ2{l!Q5+(zrG-kwjAjowDG@WA8*gwsV$W)wpHCMT6Xty zNjvBe4=i84Mc!F4a&p}r`sRg1S7AYytP{1f*mHFO! z>$I@5^qJK?OG6h71XPe2GQ=R?`xqyuwbT*}LVh0!w->1SG~1bvlO-U$FaQqcWL%RC zZne!ve*^&#Fw$({rtiLL_9Mj;8v^U$1-_N!F*8e}Taqu|kAPz@nB+gr)IOheA%M9s zjvDA=6A03v)I7>tMf~^2z6VM}U5xtUr5n*-(96GC?~=|W#*9t&k=vj|78*&13WkGI zH{aN1I%sKb+;6YE*G|9IFQ}8U{q1X!`Q*BLK<0Dq`(XKj;i+XUw=qTolBBg%w2$d; zH3s29Ypc?{c{E)3OA4D0*ob5Lv*X*Wds`)-N5^L=;fgky&XYu_>Dt{Un=Fq_HPsF6 zBYL>XzCQsx>nCy99@JSH1dq8$-`v8*z=4Kunl{{1)Bz!dKEFm54dgvo+T|lNlYEj7o>1yqJK_tGqQW$y!DaF>f{LCc>z~ROJ}NdiZE{&9V7FUH ze|S0$*ws;3dbI%d`inGlDj^V_!}oY~b-x}>C8w&_iwPdQ%m$b=dSab$s7XAS9i_T$ zk8MNACSGvdBzhj%)2pa5;j9(==d;u8OZpN99tHZ3{pLi$rg)?X-kfqN?klq!yN~IN z$_rVUzs35C>B5cDww=XI6pZwcb<7J6MHMbTk?XhOI)P5t{@6?g(9rAbEMC7rSQ_A- zY(APlmDeD0)VQkR8<4<05aS|MWu!ltE7MPL94?s)L?D{1nk3P%&*(x zs-680VW}RrHpzGG=w#FL1d7vwTBZdG<8&2Ceml?@Sr@eikUOq8WZjTMr18J4)9Mfz zOROh^HMtr{l4ja#4bG38p?2_L&`(679sEp&!JtEE-o#d0lFwZ6cr#4StQPBtW-(

9uh}r2@t;E3-R&ri#qh*D%uk=zS*n({EZEI z$|L(i42Ih-Y0q8j1szC``SXLr=kJ#9I%QXyX*9EB%D=bosDAsaQg@Kqc=B=+K?p1f z#6Xhii8bIWE^yAeO9xWFfVMF*3<9GwZg)?G#tBY`H<2w7jTYI}?+baTT|Gu*RrTVD}=J}Ms z{;Z4P)nbLXRmm)T=>epB%;(fy&hSCnoI1Ev_1}ghtJhZSlB{yT7L{ zQ{~s5e~j|+2qM*zu$7|xI@6E6jfo!*skZ51W_nyPrubHuheFG(kUXUq?u-+d17oC+ zeF)f{g^@hg;snb^dID}<1T@T`eM==cx%b_0+wT5|an#O&H+g8eO`e=uahC-B&=-(j zctz>dy>TuM=DT~XR)cLz&n~JCAe*|{f6o2%G=3VmPh&63-V|YY|60>xRmNFQ)r*jS$hC)F?`f01nwJ}i z_%68V0Cl2jKLML2#xR7zwN+DXaM{YWUYxvEpCsOlBW#?Vd9f()ja~_&TTSBl)=17% zQYSnDwxE|EhYp!<4y#!{NrIM1P2YXf6jHx0Ug@1lyy(eFZVcOid?0qg$VWUC2neyC zYtA(+P^3MOHJZ53E65x%?h?;Gv1%uk!2Pvsy&n9gsKbwHmzn_KRlUJA^#>q9gtPi^+Tcl*ixPpT43%U6oyM$;tdzL;|3{LyWNvE5R zT>xeNegv6HG|`Xe`>LD)sF)vN2a(BCs@X)vhS+dv%{UBotFbIoef15g#d5N%QsoSB zv~w~zP`57wHT4PQR*01#1?gtG95EP8YmZ z)k}ZuP7v99mS;f7ry}tY%P&3~{=k3Ls(|J8Ms>S>L(SK<-i|+nECg(bz>U5PKerYw zch6ovpS12Z_a$i42!+fX8qWz4+WhsQZ=G$|KS@*+y zf3o(6>gxlfA>n&*(k!-Q$3aAIKgr<=?FhhbseqP~ezNkTIb(X_uDDUi27k%>P&6EY zqDBh5SUzm5K!4$38Ci>1Jn}S=d4KIu;`-z9pm&Gd(UXJx>n|ys9gy$4Ke3O&3r-?) zn&*Ghgl73bOyv|`Z>Bkht0gHJ+eoxH^A5+4nGZFWD0>V2AEv%L9_#P@KV)T(WOLgx zG9!Cr%dBK)Zz6lo+uoZ9*?W_jO-ON@x1GI-+lqciy+6Ol_fL<9`*qH_&bhAZd2Q^0 z&`_PL6~e`2?CWyvy8aJHQmd%O8G#vbrYzA*e?R%#?rQrWnTCfr5u2vcj4AGM#)_?Oq9o(59(C}lfVw`fhZ|URh7y(a>3HF|C_H_qkCh~O z@xYbJi_CbQ%^uZD`#GQg+s2}!#%XoAn8@v6GaBXC{frHYnc=Ni_k!(QCWdEui!B;%?bsY?o|IQ(}$O(2PfPo7~=UHX_Gl^|JgaDQmHm**VBD?S%w6!rhSx6 zXWwq|sp*0)?jbKV?fqm#z`$Hcd+Y*@!x9GMSp8~Irl&s9N ze^Vqqae^{BTSyLp7*d;ot=BA@PWxFtPMCSPS$}PC_)ISC7X!3fPRF^xCGP#(FQ4oO zoIm08YZ4LS6&&i{F)F%W(LvqjW)||a&5_j4imtX5N|s+@VHi(bzgOeU;Ng03%-PK`rHMSH{@ZGxpsV^zjCg!pb&I z!)Y(x;+ag*@X-SH)fdAVZ%a5_G@1hy;KP1qmyS0Kg>{az9QQ}e-WZ(12+x}koA6wT{D5P zUQJ_5EIm?h^9M{w!Gr`82aTuQsSEozASl)m|M`C9G((SEK^sincC;Va?rBtq@(uX!c{Q{3}*65U_clSlMYbswiN+JT9wv>`oMwe zVM-U%gRfSLinT_PgE_w2WRPf74SB@8l~&PKx%q`bw;sILI!lkSe3I^H^F@c&o#fV_ zRQ%})9>ix9eK*W`KK6m4_&E9Hx`te4_Tfpe5?)J zH+FY(f?%UbdS4!f@%2iNBDH<`R$s%YS@E!QI@rI6;!m%;{onU%rJH~%Ela8-Vp-C)ka2GWyJM-W_{cWRKyp`-6bxQSl7*FAAx{Waw;Zkz}Q7} zVv5imPbKwG2#c4NDf0$}uG>Br>Jn-E+QW(gEh(J(K^&@mdQod>;Ym zEav5F5KZ}P{FGhhofRZTh888vD$GPz?Nhclb{kEo9QACieq$~UJB{OW52_isLat=Q z;6kP+VBz7tP}~&)5~N5MtwFhlH@kw$t7Snd>_L=pRI6K@&n@_ck3%iCefso_U-!DHRn?>g z+kdGRF&?aWRYY9H=u5HR*w~oy_atFS{Z~NtJK-^<&7AQH3!&P#@9)vjl!94l%3~T* zoE2IZbAfXR9(ax(;+zP!bOF_7325=Pi|_V_#f4J2*K0bX@nfF(LnwO}p|v{ZY{Wgj z_~Sg!B8R_oKKH3GzFCX6C<77if2$QI9XtedBSvn^nyh0662BeC$I8ZrS5yh-{uFob*g@q?ice*q?O z`nV_qV6*P;0CIxrQE}(H7f{rCm~-a^^OThrlYBh5-?*^ID)h6OWzh=GuqNFtbVS~` z0523RKL@XKoHVKbHz522l-uk+IKYyga42KyaiOvko>)(lUQ0KtNITOisnxa~Jn<Pp@fD%i$3#zZb&x-zKugMd`sNq_{z(*5!*<=N918#>2g)CUPFrFd%0xky&Z4 zeSIAOpy5?eLN6mRKtiHqg!Py?*{0ce@n_zaeFn%20}?H5H4gx2(Yxh}F6lkOJ7y2T zdm1kiI993T{F)cD3IDy>G)5+q>V2<*G<(}7lOh}Ly;l1Lp}*VULoTQhzoP}WNk2AK z&mLj(StEe4B_^$yLqzg7?jzNSAMz$_@cZ1kzU#(}P>`CxU7Vk&tj#gEz;wiP8u}g3 zY<<|M=z5wfuIY1i%5C9~FD3s;t;OPbPrau65#k{8R;g&PqAB+Yn^q;CC_MulpgUPV zbNxFkq^m%AD85Xqj}FC;6{LP%Ul-gQTo-n!v-(;6Blyfub@D%V?|}g%4NeNk-@S(h z13zCe`zc?mvp^|H4U8jg8TJ|_XHOi*@#4d|4Ssmt-ic)>H^C;CgUC~A#nX)<1aEId zEE(?|o&=Oy)iM~27 zjTbI7vP;trV?z&-qQUg;AFo5=a@ zz1RVqKel&J4J)XvTlH;IZ~V(}hbYTlC!A0E34SttJfwxv%_&*qa6D*NW{q+pTaGQZ6Cu2*fc)Dz&Ukl}$t4x{ZHuvR4PPmS zo_Y&bgs;`xjSR~W-e;u@1=?KYM|w)vMATuN9sc?xkN5pEHTp*36X`B+{0B1I21J0F zdIFkaq9{1kDf_?O9_O~aSZh-WPBoB9cv~kW@4S|doVukvv4+%7B%D#YGC>Wbe<;I7_SZ!NHM2G^q znrn96&N6}>H7Z1iID8i1)Meia3P<02UrjFJUj5e?mroyW|4YyNfyNt8VjUl>TQ?dF zne9w0xP2G+#cwl}Mq+aRb5^{7P_$C7HV)Pph~Ya^0tsT?ceD^VYex9QZa{HbC>#sW zcD2CS51^q2YT1TGdjua2F+5m{Po5M$#B|S z_FR^A9@WHB&eTRtW7lkCX^j#d2aX-K4V{BaOu@dXFTx)X>Xz6OlC&$La(k^=q{4qE zF)?PPwr}qwQx6Zw8$1g_K@$wAo8}Zf3%!Dh0sTw&(gjVt_TeHcCIlkYfOspUU14nk+b!m#WMl!n0hvc0XfTcj=ei>ZkLq=MyS&B9^iX1oDN|21nEBJ zRUBbOtxVr>5yu&{!}xvTmkJ)wur1|8en`wEYhl>3!@J>Z#de82T@KI8-q8ovi7oV z5Er1f#deN@VjLsBu~Uq1taw?fT2RCKsXbDxt*v?P)}+TpBF#b$hM{vre0n=)<^JyR z>#^(^NPeuykxdJB-5@IC(Ke-UBfFR#$V9V^ieGSh(m9t)O?b#IPvwD%aGiE)*k?6a zigK5p>jqJA#Z(qUfD24t_v%nf1*6^?5GD}p9b?I2C}fYf)7>$2QA5M4CHE?u+i>3n zwy%;hG0rMsDFs550XDA1Oacdav!lg)aR03iVvma$mGUgFmJ zJZ+zesIF9!&pwLLH|8|`z2ghV;P;&5(^LfhH9kiMWnl&;d>b6~MI@00!O`kxr#vvC z&dj(+^HKJmW}mg$m@Z0}oVFhn9kG|XEUjo3R8e-mXZZM%aNHnpiaz*4^K~Bq*M1zS zP=d?G`g_@shQRvw$>!YbS#x-|+aE_BCnru@!}xXgGvnfvJ$NBrXNI;FE#>%#ht zqKN}&e)mO9OVHyp2^5>PXqrC0 z#Ff{Yf$JE*;|eUCU-hI_443{~6`bLbge5+>lr@(B93bCBd}Rm}!XCQT3eDn4UD zrC|pew-2+V_jKD5<&Vr^WXkce*nIkp+j$!=I;L6Wf7!aLQjW{3=j1TucO<=Xyss>r zPneeCwJ}n=NjjYTg?0Z&PkEBF%i-dBZO&dpsy40q%IM%IkY@Eq^X(-~nrR!8aTZ>z z(&h4!|Mwf@g0Cjq26%|_1X?9ZY8rvo(pK=$NaZqr|ekElMVgLAf)ff+v;21FW^EX9~5Pt0CXB2D08_LOU{YmIy*S$j#> zU-#0X=e)z>fqcS|IWU^rJ*|vHZ?xWL1wMVzdfP4RvV_4(_jjlNUaHZTZ6X^h?vUim zqhUkNY3A^rOmz`}m(ft7cRG5CV0IJKt`TrPY#*I=&xUPANMGRp*)+DGPh&Kt)zg=` zFVCq=5wziev~444+@DT=+yu`Zig&CNH=osiq{pv^-QdFz!j8_^puLgMs+z+PUGrg zCqPypApo=r3Nt<&36qrQu%4x9bgh_`SPc~Tv?g&eaJoI=g3Sw!*LPbSW%d2}wD;Zn z8M^3us4lg9{QT*RQeQ3ADN(@(q|Xn`b7hb2eZsJ+F&iF{C4AII#u)0hC9xxvgmc+{ zo+Ty73AY-^YDi%d@nb8cK?!1a%cV8B4IRcOBCShg8A&d)XC8gNa&X|fp?mH*F^F+HSEw)`Xde1e=D6|~^e(RAK{a)R2Be|(YO7l^8(CLZ-0#_-ym zH{zp?#w3S+%ge~+#nv;&2WvWeMdGAI%;}JPz|tyEkeipmC?)itJWWdPQz8%^t(g5K z^g+JHk#Z_2N(o7p+aK# zl~C?5eDQzmX?jmD27z#`lg&#oJ5*T|fpKtf)bvty3kP@ViGRMq-APf>5=5=HEABCh z;Cp^Pk^0s6o$X8T0#S+a4`H zLy;oK_bmQtwEi_&=rk%$@t;g%pa-KuH1Bfi%O_>8W&T*D>?kD+M31|Yvbj#8Lt-_z$bOl_@zuO<$i8i!T=nCcW zx~UkB9pB9~d^2f9b+*`XIj`b^H0O0*xt;a3fVvThpxu&a-IC}n8T2MZao~}uc>UpH zya#Q9F@Qwv|3ubR zyIv9Ppw#?orr!v+o4qLuc6VFWhF17l1tIu)mR+C=;^(X!PzS+HUyi7;n*))ecepl> za67e|{wV6+ic}1zaA+2NaEj0_qe*iQkS2nhs>zvw%s9_HR;j?8e=^nt%vDzc<3r%( zs68Z&_&J;_+YehgCHI@6d}zn}TBEeey<{91CHLLDx69ni3$m5e&>1lgzd@&$Ud3{H zNRECyjl;!q4Bw)4?W(@q`Nl>wTrZc|g96!>!gF!Q=Y(#GV_+(3Ka~4YFU^C&IR^4& zM|E6i#URQM=f23jht;(UY?f@8)>hJA%?uqV7M(mAj)glgtdk;z&CKUvdN6ek#HQu~W5Blc5AgYhdP?N5{SW z?{R;k-9uTSu~K)C#38WrD*hCQeyDQ2w4~moY*4}*+5Ei0uK4{}gKC;+B1&C2_d#6T zX>KS80Y7EH{%;ptZOSWyWp3yYdS2CbIBTh$@L^mg%0g8%y|DQ%o$EKF9tO?Xhv>5RLq-q%ihnlU zd~sfm5@ui!{w}Rgkrw=T=$e7`>3<6gro~WBBru1FUOvEhT-nY&1uK1F3hG%XOPnaL9Oi%Lz1u|N92gg>Xkh!(_QkkMEIcN;@w( zXy;#bPQFX`K}OAFffIe4^ULjcia(FnLM07)^wxspOsJMxtL;?tH`Zey;MOVJ+*d*# zWiS@t3T@HWt*L%DTEF-iJ6+|qR}<>X80-uM%c^~gEB>cAhLGf6(hM-x$y8w&i{mwL zlm}=X<>@iGBaJue6|}dSbHI!6TliR(HnF6YtP*sJqtqw+l2>P;`#7D z8#SBsr-TyR%vFcf+YJ(q!(cDD55AN1uD(j)(Y1{%(uO{CpsHflnIn|6!;`CJm&%ZS zX!RVdj5dHyh+Z(J4m>psa?jgs=?wP6H3J`56MU_$N>UQFYR$-LH2jgmabh>-LcDr< z(92lN)_@W~f!6w>^QkSte!~iS3{S)SOrAD=u8mi!4DImd#O|w56#H3UHMC}c@hF=;-SFkmsBu-U>ZE9m%)#CnY2?>Ows&P5RhoxBIPLP`&jp^KliOC^9SQae) zQX3`J9)!%yqnnG@76Mp8E{KsH)4h7mS=|(A=@R}HkWdmklB=<%@5zq5kG~e^mGJfH zEbiV@NC#xG4AWX1Sg6_Z^N`SoQmX;fJ6{>nFC+M<|6wSn{*(3LS0IiyLhiV-xe$O6 zLW)W!(H^Mt)og*J;!Wc;(p0-~V@6KOel3lGqsaEh(;xkuZfB$LP(_C0Gr7z~H9RSK z!L3{bI$2d*R#;r~f7(^L#qF@Nj+PIZ#?Bjb$lB&UyETcNEcB{+>9FM4;dwnaI`>r1 zLoc-94`La&44mqS7{x%6gL>6EZ_*xRW|vbE$FvpJFukvJ{MIX^AxY`l=sy2R0}qfm zw$gYF;z>^!?Eh0L()cIw(@Gb|8|RbgV^uFRshd?ISN-%(d~PI6KBOeMF&A5oKE7jp zn(xy4=HvMap5|IotNH&-oM&dBIK&!sqBiHy^}gs=vYrSMD8`x2&R?{oUM6l=Aa578 zf4u$y_W?C|l#q8bwJSrgZGcG{g|d^Z{QQ41b0FV`Ox*fUrsw&=@T7Plv#p_*;xuEFA9;w4`Q{_4hk5ig^1jXJ1t8 zME$P&c|cAhvsb*Gd$I*e^}-^0$=RL@fV~6N-)Ki_K#3X<^X~sy@XydwdBP3%4?$}z zrZHY>H1G3lG8dxJ8>n2%d7kk9%1K5f~SB|%PWH6+JT zd$b5&1WJ>Wh?g)#CX{;T+p?s0f?wgnO|AAq2-KE;de z?{${lH*uyv z$>$vB1`q0<5P)HLx0jQhhcNsJp0YeGHFz$h_G5XZKcbRo9OJumJ1QAUgz^}C>G4h2 zRjANqjjhTYqR!^yR8^UwZ>x#N?-%P{a8xYA?@&9rQFp0S55pR&u$&aFz4!Y;e$&HN z8dp&uYe4$Jz46@7oZB0ZUb|qJcpQz940C#2Z@e$_sxLcQr2pljyZ`8>h_&R2db=>4 zDUy?T&;6krc9*s~>XzOr+ot#WD6>W5Wp7BI+RuZ|zSmq|yzD~V@TI;2?PlH`jETc9 zEAi5T0K){{8s$>;2Ca4vWPo2QQPhen2YY1vXPnc5am#s{Bs=;0Sli*Tf*xDb}6MOI>_FK7}6P9(zJ(^i&v|%y~ zk%FLAT_2Gh78r%}&)yg)aEe81y#c{|*Z{O|B)Rgp7&7}*2M5x4d?sDqDmLKNNd!IG5|53;? z(S07da5`vXZu3*)A3*|Z>=#jORuWe016?^qFQXH$Y{yD zd^@C5AQoEpd=(iFA|)bz z`85Td`uN>y&l6iNn{7$S7fvXgyi7h;eB?i*aa0fU6%t2uL?mFI7K*1tFodU?Bu7u2 zji3~nC@f!n7V$0CrcvxXb$^CAS?K(8?BryXclm+G1Ya5okk1Qh=WKePx?)*;vJzJ7 zDd4bTHYJ*{Fo`(&)cXAPy41c2JFm8V9$3&jgWnevRM&4s+3FYq|K>$dX}kr^U14#Z z7Zg8QHS4SDwW^86<(u!n|A4l_Va$n@=e0lAfO8i6_*?sV#&W2d-tV6aqdFr7E`NkH z32_Jp=>qp>aoRr@1=u$2&LUHy1-t+UL+!pt&cS3i73r2<(0^B;TzZEgAEMx@=f@vY z^cc+4_t6GJ!dA9}NrU8r)DRCExS+1zpT=n7ksn_l2pv`zZ+at6Ty&~CjuGgE3_=Ey zcB&gEf2EP+{RWtfFfok5t-h&AVE*l-CH2l-Fr86Ko1%Zo1KAQ~BjM?Y}4w3oiha_ZqV=MZZPB+nTk`5}3qUqX~!Q!P=C2TXL~cU*m5 z_u89$NO}PVgT*ZD2O231zR%S?=%3)GiJ%1MXYvbXl;2(s?S;T>&ysuSZ z7na;V#v%`vZCQ(6&9%3&(FB&NfX%VGRf>$qavXjFr8ap_Zygn^jAMmPQevKOwTJ@q z8a)zA*p@l0SnROzQGJ@MwFqI%KQ9I!1_+;81NqHw(^sf20#opgK6a301b!lgY>_A< z{5i?CSzly|Kjn}*xlb#i;+(eX(KI}qaaXufSKTsCG6)G%{`(Mq^B(Y^@Y(bg5QxA) za{?_;yvAd5>>qAqOPd`ZGe*t%T!-NI9%a#IsC>%%u34o6N||k{s5dGqzI%ok=4x~=aG_4yUXZUg2z`DFh?!%R|b%p zf81rowfyi6Xe1*Hv+{qu6m{twMXlKD_=-Wx#rt_SWn8w}kNOO60HFhnMtfFAs5zmj|NAOs4X9UH9J9 ztwDi5(wSw4^y$0hFA?IaNWBd=64`bvPaaIR!Tz+me!@L=zX-wcToA)!Fvtm~2WAYn z@yFL;1Q<48X53!xaP>kZeIPl!{rYRm-p|oS+Vy*I+P3}u$uuFC(w&K-SZy{EnX?0! zlTTRyI|%REYV>krubAEWI&8Z91*S+68XtDqa2)nsORtQGix-JbxY}C@pMJ{F%7n>o zFOma!8&2@70>2j#r29o|y%t;2&Z|~E=7u&7H8oV{zR;JNy(@%cX+X>Fbd`WjUvAhU z)f$0ey=A<1B--jDOvr2jxJVebrn|f9{Q^4=l2n9OcWkKJ;vY4y0zbc|Ye~oJTopnZ zMh@b?D;-*aAzAxEUr4@xVJzP7T>T;Y=9iFX*S&jxP8FU@zLbnkN9Y~fdK85%W;Iu8 z#+z(nvObWZ=y^v&0b;V+k+U>ROVJ3%tex>29wT3X`!v7X%=&R)j zEYOn@TYH6ggjet0(ih1AUw<`+$yO|>si|3X6DjedO*pN+T4&w}{|Mih;7>elz9q38 zcG+16F>&fNc{h2U@RJ#F{J`HV@;ypECniH5zpKvw#;bejr}%LU#FphFX6S@pL?9el z65PLA{PDUJ zrnunfXuL;J=6$Ba}Hl zc-x%}EY7rsquzAuSo{PL8M2-$#C}K0w3DzNG_0bC9xx^H|$CH5AX$B z;>$(5@6f3cAF5CqP6!%TflyBYh6!o*w8Y{z-!ajY)$x})2dk>noz$i@pVTq_|+1ic8uZ#@+y%6qNVkTODys zv(sxLsU6kDf$GoiH%sqQ>>Bo#J>9vt(XXG{KHf~}IO)(*R&Z&{o12uIO?iIRmLF{M zn)To9k1WH!ZYP`RzVxz?sozCWFk&{Vr7HPV{UT-G&M|P7=$BZe!D72`Gn)D;u2zLk zvf?})gn{}*4BF>o7(s#YQn#AvA)3<-!1Tsf(M{r9j15NT1m>Y`^4je@J|M|!lb;-f zHs}#n$@Aj|cnw*P$10x;gT8AspphXFx?_`;!^z%4SLc0oDgLzq5(q=*ng_OYKTH1h z2#PDP^!v7Jv>Hk^?cMv!Lk8e-Rqz$6H)QM{LK=qx%FYsQDsA??X&(GVRbZgM^+}1o6#Xs1gXCFmp zk9@w}LGeGq)WM_QtfbZxi9v)E(?XXb!=j{%C`d4a#pC10_1@+SN6GKfz{{ClL;ICqtH%DZ&aNwM5Ep*u?8)=f@lJgC+6G%l!P!Cko4LvxNj^q-5 za+amqQPOw%Yj=sCk-_0V4!8(ZkUY6iAIfw?_lt*Sy+p_3CX|YhS?uRBg@SsL6zySg zUp!>bXF%1S_JlGl{r9t%roew(3fkI~uLrexxOGQZ>7};yvk^-D9)gp;W>8o;QHcys zy=uUrv8+19!E4vyr2Sm@&%wYN6pFQu)L)*^6swfoCJfR8o8>CL@V?-FAa<6uzEojHzpS=80nf@blv-6d42WEvesgTO4Ca2Pt+tcB)Lo@lvZ=&3A-w6f`TsC{%67!`R z#ir0kLvQ|$Q`rW>jj}K`N)bLqj3F@@>Yk%d9d3t<<`oxjcaC^BK#Li9^?%MBLSDfJ zCr=r6lLeAd`BdgJJr^~oi!c>+qrw9*+q!s9*OrdvE^f%$>gxKLLrLrH)rSm^>mKX* zQ~0Ejg<+8ct-8xlU$Lp-_N{XXX9~S^QqH&}(s%+2e_I(i9PTFphHK?^XC#vwo0gT#@=cJB-+vT9A zg7s7&O4UfO&B1H*8}HXelGN0X+%4a|_gD^pBy7*%h;Q+GMe|9;v_SRH`@@Os{H`Ly z*=-+6w_|UYo2*#q34X}4k7*(7xP>BKWjf~up4lE!C&&X_0?o|8QQBWV`LV+-`)x{s zS@-YFzorq5Z?D432t@_qJKNv5S6I{djpTj?Hk!oSR!;o{qPCeY6f2Lcm)#};v^J)$ zbxqD9UVh3x4sF(c(diP>@p%GztBh1X6s_W*I1QD7;dOe7`L!(HCU&HjSy z$Gi?)+{m+Y zEyoJl-O@%!h(f!TLpDfX3-ds4CZ57!e9%4_(Qc9c5nn}JO6-HeqP zC6BO(Fnh!o7xUZsoqlzpJZa)s;`w5F^D}XsvNFxX3E1zRWPSw(-al(q1U#-qf|{wN zOw-V<7)qm!w3&xZNO{DDPIvZdW~=YN5KX6dNWzW%&|?}JqZKx}BzA4EEp#Idd`U9$ z!)0N*^=>C7nWsE)jeAbdvKN?Q7>Dm&D~M8}Tw^)0KiFCR&%YCp-nkbZ!`$Hq<53kw z{9YPO*;%Gfnl!xyAx{tp&n^7@W3;og<7aBwM%qkeCU5S% z!WvxoMbs|XHadJ?+57PBpa?pT$BabtTp;moW7@;~7~4cGe>=KjGrzR(fSdB(B;+W2YoUmhMN&WueqnjeB_@zpT=br6j?I%AL8r9P+`-64{e_n_WnvS(Qo{Oz3aGpeqnP&tmNf8E@F0jJn5m$*iE;5E-64)g?9#9(7WN}X@e;r&@V^3gQu)2)u9 z>?1|nnbTZ^qM^qUTOor%TVVQH(734Je@G;R3*lK@6UEc2hd9ops(F3XM2^NxYTl_x zJ~A%=W~lH`gl6&T#`S@>12c7@P;xf^*=CF0eKq2cnVUOCY z;H8DqMW3n;6tqQ@V58TA0NN+gyd}IZ4kFlRmqd|trHuU4g=8d>fg|X_YXN)%)#dR8 z+}LDUTx73A@yDF!O=j+}5mA+2KgcHlNtXhD&nH-cKfIVuXr}0t9y8Bayx#B{@67Sh z*mMx??NcSJ)6W)T+2$NRwQCC{h*v#95yd7H#uGNE5b8yA{Nrkp+s6Z&KVw4S%B+xC zIxLenQ-fbgp_{^Y^E9Ut%x>B6G731JQ}tvU{;5PLE?t_Qq0=h-)Mz=By_4tp21O73 zLWXFAv`cI6b(6{N`SvQK@1aQ{cVzn7 zX8ZBM09bK59wbR9nVMmjO^a5{VTXZ7o&q=gZhQqilTR6kOvFt|1r!<=wvxm)|B_VU zs=lLUMc-vGeR@mMY}VvS+PLjKNLq62tJiJ9cd$yy{z%~Qw{!s+0}k2|6g&tTYEAgX z@87<@Jb0u88sY4*M%v(zq_-X)c+4WSm11;?h^n4KCI14gX$m0UKqtSuBmyM&7Ja5C zgD1VHVGU&i_w=IKK`h>`l0=J|pOZjf;p{MU*qipa)SZ#R>VyYs7Q!B7bQXtcvxFl~ zRBnSUZHeB?CndUyX0^p2la*D9JJ=Ftp!HcGI!i#Vp-qvZR)4B}-SwL_Ve~%+F(v&y z%DDKUEkEjOw;Y?@A?_;fClNi;;KnAyaIxkx!pg;~Ev0*~-qWX?koRvvT|;wjp@DmS;7mEUQA@hePtjBota%CG)%S_V#l za?QYl|YP8Y0dDb@VgqfPz}^=>8};_JswJO z>;^X35z_p(8mYSkdQkVnrV2jBOB9+a&jM|y_(C^yUO5#om$|$zHosp9S%d{TyM=po z$-b}6z<@17+B42H%8hL-G{jfTF*a|Sk{5)jLtDsggeC8U9dr*m(}2qHwff-UHx16b zS;o6$_^E(tX`E`?CZj{Sy#L(fQU3XeW=yJQ$7q@fhQQOVlNx^SxBNtF;+htgX85!T zT5ssb+ss>bm9`CgO(}Vo2tH`R3mp^EZjpo!#WwRlwbBc=-tN3ph8)m^b1U~cw&QnU z9|}Bws_>s5&h(zLss9tdcw_8%!)GNWpo2(?o5jV^iZv+IHs>%{PLH8CZy{OB{n(h= zBQE%yJcusF$SPrqG$o(U@=m+Rn4Aqe*i-@0UgkF?2#u%xr^OhM`o$fiwM$1Ls~UHo z2ve7`kOL>3vh%yj=j4l2zh&k?AJ#gOC-@UbDn&?Oz_A5!qC;GNfXSPdd~WEAETLDS z<&2Vgc(f{Mf7*mRHxhSxVgol*Hb`Yl|BF-vO9<7?K3OoCYLpcbO2aHI-fKPVuW%&Pni)oVi~i(me!wKOm|>yL;uEtzLmbpMHkPV?TD=sWFz;$fb_q|%jd1tu zf6=*+6epYWW1yO^_?+}^ykXV>ul?%ahU4z1-G(%SYxC0&!&Wgy$<%a7=(y=e4^`$5vG8cjA?89X zX)0I11R5o0rK9ZGQEdlCoiRB`GtrI&fgTwz`;7$QX=?znwmsu|Nr9z4$b;(Q%DvMp zYk#}QX3k20#}5**QbZAf9Rw>1?vLIZ7!+pcZl*P?N%Tk8TRhqO@kwsMKH}_31oYH4 zr1^->IBZ0n{AJ=-ntT8;UX0PUS`|0DJu5!r2uiweTo+2ZNP?pHj@-OS8b`4VrKXw% zNJp(qzFhLkKb6S}keP_NO6?oin(l17bsyj{SjURi@*?{U5{{`{R<^0ztuqW#_APgp z*NM(*lV;uFb-VJq5?^~L>FvIKa18ArKsDM5+T5nl9H-rt)uFBUa8{#~al{?=auaZusk-AVK?P5imaf4E01d2;X?P-0C8AW*{5{CID(sGmP>kD9R-WkGN zHY;ByP8E==?u(RLsa>t57pzGfY%oa9uUs7e1PNL1ew|-q5oH&P^eJmek83OdqqH!1 z4F_Ch;wdSb>U$2n2rcrS?r;9hMiZfPY@)z8Pfy^;zYGdDdGk}9q)(kI5Jpm13*7AR zYlY8A;ae5ZGCahw9y}yxpqTlBPzBg-zyJyXs2lAFR^q1$Aun?qd+cIBAT zholZs^Ae$E?h7*{$u#uw_=g1Ek2Y@B9qVL)HCb&Nw?>Kv5e4Cvx;sPb%}m-h1-0j^ z$nEK;%{^@6Cu;C_*fx}3^O|38_#M9SR^NY87G{E>&FU6zNjtoni)dWeht6JOE#BOl z>ciS!&@wIvX#dz`kil>kNkTocf~RjfwaQ$wUCX9^#ZU_RU}rR3D2%rTHTRee2lhp* z9;(lu>Myq#GqunK6>WM*f5oHhsg+JJdBc%Qo!npDa0tzGJen!fnGB!SQhB9y7)p4v zOgcrHgz5xRzjKeE-VD(kd63Fu3F8#`9a&S}gX1z-p4K1hsZ}%JH7c#B7%gYSLmLjG z>57>7nA&{TuUWe^W=T3y28cyu2l-2XlQ%b(OXV<8hsS5|NB_ckHLBj_xYtXulgn~q zuYC^Kbf<-HD-G4rgjZ{vL}8uwSsJnS5<5~8Z*gcRG~U0j(=LlyBAq%sNF334_y57$ z_NZ2FiWn2lK=tZB?HHW57)Xw+)AnPv@7sg3W`fyeg&hW_8;MHG5$iWkmR~9EIJD;j zSN1Wt<-ED3W}@~EcDG0bF)!8q#kgAVnTyZs`~@*OH#JwV1)4Iu!}5=328bG=+%ppw zxM$OH<@(g205l{#-Tw0pDo3IC1=mcKe>sS>#~Ahf=O-eN|D`l_9rLl*SF?M`%W>>V zD?DEes^DHs;3f#Fa_U~EKYKs#;qfb*{KbvS& z&9NPd7NY)1w#2As^-(8SHmIL!Rd!jCBe{tTKk=SGevyHq{bM5y3d)}DAHVhNvMs;_ za*!Us`v{qd2~!B#{ySU4ts@tCe#l)xPy3;B4%G|>f>2cSJeRGzzW1)!4|qd$`X#7YqQ@E>SkR?l0D_?Cw;U?}QwL6=qQS*U~X+)OXZ^Pm5r5cn=a z5dFKLxNzDm0iN(H6X3xxx57#jjmqAx`22I_DOIb|4&FfZ*AHjqx~AQ<)yLI_qG9i` z%bZ&cf47V;T1{Vv+${SAsb;@l_o=eH^D^co)YCIRrtFE3`5Tn|B>7m#JHQSp$|Wr; zPi1G;&~;YTNzz2S(MuGTpgISK*0b3yzuKYwgb{aEU+X<+C<-baW19%@;zs<|CF@9V zu;2M!%73Z_t&JrNmUDWy7cf^v-3n5qXvjs)TL^y^E>*^~x_4;PpZS}ld133G`)+6d zdeoFdc{2TNan6%qniQ(6cvqEXbNd#%=Q`MJ&V~BuJLCAxWk5-fYAbg~eTX(f4GZj7 z`tN=xtaKcZx?fc@Yt{5MXtATTa+;ttA7c4F}d1G#!HnQ4%wu|L zmB8$19yClcNpmSX@8gG_b-b_rC5QHHH0TdkvSPXKrQLqA@A9lWbII41P@QGc*VzBC zS&>A;Fs(ntyZ!$$_LgB)by3%_3JORZLILSgKwwSu+|R%7&wbsOdiGv1_gr($Ip!FK4%+pDt+tKGwWwyg-spAxb+bKH zwsjTdDCU<&j`?JZXh_Srlz(%2X**K|5bbvO%oBZVxQ>X!T#FGYY>@qX(&o&&{(y~- zH0XU5jK2<4FEm7Pf|GuiVD}Mnd7timiJxoeWeNN;{d)AtiB zTfROuqYT_3H1D|RNpxv>fCJU4-)cnWgvl(xc*Ur{0=(>raeu%^*2N&g%D=!(V7V8s zVBPJIV*hOu=qrBohvHAgC_~iVx%&dQz*s~wR$nx8lZ^h`F(k9dZp=QGyknojYV1IL zxGbBA*3%d)EEAHF(XL^Y+XBf`?lM+}evHt1K|s8=(d(j{KG=5Bx0N>>A3_Ai$^D}{ z7UYy4E;5gX+v}N4d_Y^q?L*v2ib-=@i;wG#85wlzMLTBiZO3qe#*bVKCKTTLUNEh(VTNVHFp`KE-%t{6I6Fh3u6mjdfygH zEtOJR>KJMCNnosVq|8SrG8z6+Tg~%>({5wyhC($fmB(MiC-65M5r6DplXJCQ_-0={ zEA35jGf;Ojz;avZF-&q462B*cX+)YpH&5EFK_11Z?rwZ=Karc+z?I>wEb(DI(3A< zwDtcqnZ_KPbj2Mr1}bXfWN(>`fPaPlIZ#!=G@)AC0U7O^)0sr=XG)Z;NYnVJL z=9D@b;oTWBZ{gC872A~r(EfvK(+MJofZn9Zl1g?)e#nW*&D~VMoyQT8YA)sS_jF6R zK6_HTbi}CEuknp{CsIZ{2}Qt|#(-$xa|%r)U$933s<5;AT1_I;GGQ0CsQ>J?Zve#c zp=G78;Ngcc59|rCNSUh3J#bYs&W~+GdLl4io5VCgHhBH3FN zJz@SOGU6;6k?dWaa*}wS-@`x^$rJ1$CcyHY3tS(AYjOyi%NpP+1);|?Q-+33<4)8@ z0#FChQ^D7pq+QPiU&8m$iEA{^{U(Di+>p*%ceZ}md+g*ijS2^8hnQ$x-Bx{;?;0Wx z`$ChCcH1BS&VEcBs3h*=N#xdLO2_> zM;}Xj(k5oA5Y%8(_;SrYpN1?(aimR1WT5)SNf6xZWjw0KV`!4-qca+rH^Bl9Q5g?U zR}_c=F0t+`h*8N>DTzfSyf5Ode>Ih8E}_PBy(zRdh=Jd7GT83>)xgx zzebvE4yY<1_m&7h5KgbxOXswRsurBRV@%g-oC1YhRbWa{M;aNh`utVvxStwfBvJ&f zN~H6`ey}mcSiNw4Z}^@D4W1@T@=3 zs^Hz2FUXfqHny@${+k4a2q=f3Y)RX4j1roK*KGMqnK|Dx(fSb*-fEJR+r__r7^e81 zq_=JA+S+Pwv4e9CMZexD(0$58Ymog9xptpE{39Qz(hljog+Bjc9YdEKWTNGJ(;HXt z9DD3|JFreGfw}c$aQ88k$x8r z#}Va*#aB)4gWKp0ywJT^%+l16Xm8h6wSpa>KVeV5haGgd z2bBc7aQtZ5FZA?CT;p>_J-O|~mjG6b{cqA9Aq=EUMkGBf6Z#(Z6@>1lqB>Q%+x=CQ zeJq+>(F6tyxvirJoEW`KhK{%kz?%V&9&qE)kspW>h-xRimw$pqk&^cdAFAc5K=6k) zXJ^gxEx1@0Z5W1GrW8E*`ZU*QcV64a>XaHKLX8&QH>5~Kbo?9l+VH^rtK_2opmS`%YHQsuMW4%ar$eQuhvnAfay!o2M}TqQC|GnGAqJ(D<>wM>8AVE2sN|e zjNEL1{6a)R9&aiWnR5c%N=qkYx zZZU3(=RW@o8JDt$&y~=P|KckUn_4y!1HG#4 zt%7q9@MDkMUh{j&x>}|MuKqeVv+a>oux1-4SnkTdI6mN`TnPf=dl>I2*#maE; z5>KkL2Jc}x3g7OYee#`;$kmMbI}Bu>PIsM{HfeJEcGz`8bf;dWWdA@HY8p3VEnd%- z{FR-)0d2FS9136^n|`0I)nO6HI)rc3zo)_+EaaYn1=neIEhY2QyT=p7KwbxTonC3H zrn|Qr5qeCx9+@n(7Hkf!)Knj-dV~V1UEE^f1Zi72;E?^FvG9*c;aGGV#vqXE_`M>P zJ%<<3_HgV7^j)!#YxWJ5>NnP)>3JbGpceP7TCq4MgmYAHdU5I<7z~oqKqjAUwl=lz zBOeU@<1of$YqOT3IHWOfBQ7Mr+(SK@p1+=?_a8ak8Hc5K&7{p*ak>}o!%`%0R>r%- z(n)pLf+=4qxUcL$YBW8M|HjZOi(2fs4G`=mhnvL?h}K}$W-pl%W`S44ddZ7UaOxu5@z4Y1AQniyP{>uthz~!HCW%Z zOFhNJ&p0$slHyu2%>QH=$SNP0XpP_P>Cd{I*<|y%SE0@G1r7%Pk-u;unwq_XU2)H1 zcEX!oh7ZR(vt(V{$rR;He(CsQ*Y0kE7-2_Q_#&9wHjG>nf0dDkN>lFlUgl_Dz3MBjd?8uuk``*5wo9LsgtfU9;B8q zDr6shBn@Wz5co-TDX#@Qzj)VDdAyE&OH7X_CJAfM#!OZ)}g_ zFN$Dj7CtLn(rE+b^<{&@>333)aDAd-d@Ofz`f&ONZOjc?P&LGYF<7nB_Yah39YfrW z$sHbaZwFXCa{$sNmDay_bcv=v|8f&hI8=%yy}*v6DflvTbS+0#Pi34R06by(s1i|XM)y+gr; z;ZJbkq3jua(ykBQwM?+RF!|wgnU%$~f(rywu>N2}-RUZcjw3>tMrz0lN-{Rn9=L;w z#bcC-QQF3pB3I%`^LrU2$-Edwi%54l5}>61&cUJoOBgILMpXwpqcFy% zu!|P(ZNYC5);<)5UAC9NX#9;XFond;@9igOvX_St)va7_=C#3h?6*t?3G23xXpgJ` zqObU~xlobX${J2%FPl#bT*+7uN)&}lz{3Pme`@%>MoHJLCUUM=L`BbnZH<;`^~Ug_ zDpAqNJy^U4MAecuLRQzhAxZP@T_Xxb!md^=V{M+b^rew#N(LK`CJ@(XxpWbW&=+E% zgJSyUt6Q33+-V1Y**1{p*=$0Yy6&1mZ4GK z$($EvJ$*)+xttjS;>l-o@!OlU%dd~8Pn?rcb!&p&LMtn0aVwZ??`>1t%3l1nLU;8_ z_vZudFa#;52AK$FA4BB%y~pKLDPZ>=(~H*fshZixugsj4NZ250rdC0|RvmK7DsIPa zT!)=e`e3udhe;DtaQzJ2w`;LjeNM*LHa9=}%Tu5ZRIvMl4*Dqu+q+cL-f8@Mo`tC? zDX*-pi`&i=46CQO2T=!@TAnllo8)qMV_yD7V-v(GM0?k8bK1KY&30=G&>EDCpXI8@ zdF49`MNyg4WUy*8295U1t{vED>L1Mw16D&H>(iewwPtS(Qnw?ue3YJ-Wt?Q9`heAv zDWKnll1jb1oY9}s)3%bqU+Xy5cD^nTlO9l2F${9yK)*IC#JD_!Z37XlsJNFs=tMZN zAD&>jG_v9pQklJPwJ|~0*CeH{t{;f_P*?C|$_2sI)0`ObGWeulpZ?olo=mK>ge!Z^TE}_vJME?+==U?h;=B z$PvjF-Kr>DGxYVomKPf6T~Y%Xkc*>FCR(mQGY>`F3XQ`U-HM=&r83c0&wr*iQ~z1t zL9lfL?4c{L+RyHV)voNaqA|fD-Od;G5U!_J6zw&kn-?3;HdsYaQQvAI1-b)-jR-UP zI&~?iE1A9Oc5XpJ!CJ)#<=t2&PAt;hEg!M5_sGFPK6=WF3Mu0V&mk0jd9{_$==nsO zKR8;*wwTX&8JyUM5l@whn2)bhh+M}FYm(ZQvNc}}=Ok&C`Mw$CB!JY0s)W8m)k1v} zIt?H&fu)Rvpb_{X=mN1Ppwth~Iws4!ol%GqMlGY3L`jo)MWU=fQRk%YgYCNQovMhP zQ4~w^PF+zI#`LW3%BkH47t1GOf|}~rk}Q5{3%Z4 z7gEcM<|WfHwQ9L^>g%$#TIO_1<)nI~t~|RxM(o7qu?du&)W`m0F36I2VOk#V?NKFM zkJvTa*OESf9R2#_r)hY-^u$x=AlA=YG~HotEFDI2T|A)sJtxU+H3dRSFf8+IiVRi) zLW^ebEty=M497B%OMJyYtc_d!Zn0)N0-M|*_fel?UGY0A4psC>_lDY@kC(TceHGr+ zTr6cjfc_=GbNS(`=e;)sC-vt;{SC4CB~+~-^W;$JJOx>rAV{9nyR2(WyF7Hm%18YOyQXCmsjNs2X?hWt6i=x5K;>p;a>V`JkGd%!U zF-3s`XTkJS1XoU<gXEF1;&#L?z zw=bNgeuRJv``_MyyC7}Is`%)D<8s6Z>f+9wRk$-v`Z5hLrU zCJwn?-B7%%_g(00Gs9}q-eQs+b94YH1l@wl&jW|YQ}?1l0WCF!TRsEBez%M)HY7;hL=N!2~O>SKlv zBBdvLV&jXM8O1`=PUah~!d?3s<@25iQv#HeEt?t9@?pYpj$NrepYh+L(-2EBPAv=m z-Uk>nY*?r@`KyWX=hsofSMJrX^kg?~2<3vgf0ue}{ry~r3+)QVR0A~<5ai*Az+ovf zD0vMcTo4ensm^+HUZE*68X}*%6{Y4x8Ntbi+Ov*RB`V`cS$4lft;yM)6`$L*GZ(R< zUl*v63a7eEs&R(rl~7Jz8rqkoEkB|n41VPn_eW8@%%-|>Fy_y&L89h1^P207Aio>u zw+e=%JII^~#b{f(y%oGp>xCN`UW&|p9&iYPu;7*VO-GHT1zlmi*~(FY?bE{jpdKm7 z?T>1Tth#lmF#dAyp^v#@c~JK~4Q9`yaI|diSIDM|Nv?<)HDdfkK5U_-x!ub#;+c`0;X^ZY~ zp+0lpV(>-b`#~|=`W>nw)*)aKVYFmsyIdY~Ceea?t+Jqll|3V1rF`bb3I7Qd%_fu~E`Zr0_bJvWNv;)Tnm!b$O# z#+Aa3Q`g$CXGP0!PQ&JB#>vY~?&l#&cgkZP$6BKs-(kfNBMgDoZoLAH8pY7c9w+6S z33wIWpDku^Z~bO~vkf0oR-SwZR&-$Yd;ceT8anJQ(5k~%27$1?6cCed#uoV(;A|K5 zY0gia$)$6sn7!0Hir!Gqe5&i)8gIjHcfJDyl?4uKak{_lHdJMcrNjJSfyq1%B6UBV zO?OY96w)7%DSuD=KDISR<}Qhu!f##dSs^f-!(+RXU@Zi6QPp%vz?bwK&FW4g%0X~Y ze^*2uVcldUMtN;9<9q)Zz`tkV!0zei^!AKNe{+u_)JQrHWpOD;gh5Vlw|F)8_@NcU z?Ae#Qfd@cz^+^6bi?=0qlM1>$2jn;QxX4SxZrFWfN0KFCP$3L~Fs;7>!0;lFf(Jz{ z(NPnvl+cD5`23|;(R(-i9=SjEJ2d_QQyJzW=5g`_;mIP5zCobK^|lnHgf2fM1;h+L5hO|J!Rr7K z2~B4I!(zQptrikqFoQp$jSqc^>;js)^K;oigPHHsy9k6>%^LtmDT+*;%VwbwbZ37H z02B$&Anmmhrh*38Ay3I*e@1OD6mz&E<{FkCbFTYaLqXnr+G=)B*Iw00qb(=#fGs@7 zr_|85{L)70CnzWA-zFr3X$K&@$ehUesMa`X*i)dX)xCi-=V=MjmMRksWg)koQzt(2 z5&yU#$*!Hd;RzZdpURcD&*t-exk;Wjs)VxjYD24bJ)JR|gGO+Vo8DgX>e1P+(Eb@q zOV$?XDFMSbh7Wb$_0QZmeSWUM!r|?8M|DyL>PXjzQk(}JoQ+8m`-WGlZNn_@%zZu} zgL|2YsiV6*2rz|LuR^mVKC@l#?B zn5NZ+zMGR>0NnLwSJ;OVItnwLvPxwRh)Zi<1r4C9t3?95piTn{kV4QvVmT3-h{fzO zAmrQbs4io=a6v=V}`d1%_)GE+@UWlIK=J{OoaoM^@CT#W@@8MyGJ_vRtoHhwW{UHIc7 zynsW?H569CI*wY~Z@i9aiYy|)EtBE4aPhJrmFfy)<(}ni#k;Ky%IVvteJv%7uWdkf zAQU_8Q}X2ylseFYq6FpwbZZ2Zn2Zk%E= zrBH51%Fp;{KrH=`a2>bR7Z|VEdY=2UCYXQOp=GN_y@A zeYxwy#fk~G4WXmf&q@wvcO1XxXpOLLtGU@XMs1O{#pk#e9tZ`4yDio2N7}7i4rxV| z9U#>YufUg!_mk(X5qs4ImFlQQA0n!+8M}Bl?a{DAIdEYURJ`D+g6XkH0;uF1ddcyN zB_M((6VjYSOMM}v=kJTYR7;NKsF)RT0YAFJ;r@lPu+?#9FI23%S=tkWf7`D1nT*T$VrSXMV4s&W|axBCAtNDsK zM6Opy2XC44ZTAd7ux~RVP53*#EE0k7|2lmBUSM3CvLp$gCEU24^r|s_FS5(`EM#_E ziS|;F*`(?1udBW&QtK#~60XUV_K01htB2QD4h&FE5V>u%XMpW5g}8SQg@K6POufcj z6Pbu6PN6H4@c#-)q{jOz;dZKS z@FU*p1g!bZzUq5d{$f>d?drO2OW#u~U0M~)i$b`)nKcWG)+{g^MNPc#(yjX0wrMDzj$D#(L#VsvEVLDYF$WMp0AGMz>2#?v8>S<@3 zngfDG*x{IxCeUs9v1L@~g28{%$T*2wS0ou3cKSD4EX1`5(lIkLBOke~@{u*dpN}G+ z6x34v)osg@IPU?fuW{DUv;C{j==@<;gvO=tcS-Y?jw_01^9RSDlX1FHP&>J~T0rw% zDaQ;bjMe&(f5|NTQ@!e5{YY5FTt&RiQhpf_XqoE#x`zxi3L(umsr!s=3U=XTpe+W= zsu#QWOP)b^AD4R}0i#Z?T3e}3t?cA1VCtQIp%3E?rtC>aHO%cq;t_sX<@~xix3h~Y zjlINcOXgg_a^yu}>&{^D$Bj>;7l4d8#QkfD$_Ge77b;SA+-Fbe($-}|x&k*&Cpn!VZ3Do<^Czqs{1nVl8mtP5;7m%wbre30oV#ir$kGA6xQhZSh@9PT~=-6%6(`2%0=cD$rT*I)aUZW=G^s zos7pRfQCqjdvCd`BBF|ds%73JNmCh#KA=Cy0TANkF*%@FUGS(f*{Uex8SYVteD*9t z!6G5lwVCNlfS0X zOH9J|AI{N|;}c-+XTV)u=%d)ac&%G-ApBZlXG2&T3)XN>{1|6RE`i}^#;)Ucf-iSb zt_#g@$nFb^M84U7-nW$fph`cmep^aJ;W^uWO7nPmnV#{)hY@Iz8lF$T$@tK<#*P{m zt934}7`cEFqZeGJdV+@o7Cn^>vfY1(q(JHVIn@HjK!?UbrG}6`D^6YXr1+iM=or9YjC8`!(jyk_L9Pg5FvvQBFT0`Ez zyEc7(Gm!3_P$SaPy8c+h@Ne8SVT@;pN5kH5&S^Sz)VQ(E=u*#p(W@V3c^93FQhb?8 zvrNw7)=<9SwVz_&SsDIy59dA%-AofW5vta}h>>d|W3|8@qXDosB^7r6MadeVjFUk@ z9YoS)^(N7)4&M(IvqS*qqR<%rI*bFba?WWiz#34a2kv$fvu@*n&oAddy=xPtLb0^ncI-P>5 zJV>@DamGCY80#vmDkX}QKurvT`r%i5*ptr7j{ds!+(>G;6u~D$>?6NmzDt5`#C!I8kHm&j5&G?J}T7K2nI7xTcUVVYo4^TVG zs7A9gF#pm#Pv6B2q7|-{Amm~sdXqpzFqF^ZbM6dxAaQ^b;xzMh3yAufXk`dMwF$fQ zrun38Z|_1h6a)s>1aLVHdWu5s_6pg8gs$R`M(~}~k@2lvK{ms3`-WrFR;HrgrsOS6 zg&Xmm5y@rDVq`p0r9RwW{U)D$#-SybNzLu6XmK30wliwo%E?S2Le78{Wcum=aF{V; zO3&iB)M<#V(SDSXcJfXIk@k}=y|Y}_1XyREh#!juknwE!%qNndCPwW}0&NsS5LmnQBWaqeP}hJpvnSNqQcBBql@qHJoCri zj7gCf%Ge&TlRxxtmo{HexoU|!kB1T_xV1TKgu(W`d8E{q8djoiNmAt=L>O(r?T@>r zt2lzyaiLU6`Y)B6b17OTjyYB$-`zkGVu)g&^e+$ZJYORH`XZ@EjB#szvgST#mq6A1 z7J&w`y>rt@wF1Uh!fk~-5cTy~kRK9=4}!XDqhu3qO_biy`#c@EgD}^bcew$8iNTd= zx0+&!9QS-F?1mi zDbOK}zeJc1O_GXN(gZAGpQ+Z_rSHk}tOuD8%HZDebmJs}X4zo4KkE>+AA?rC>URX9 zRYUlX$DxO(7`rTJn!z{-?FI50uSPNizw3BUky$a5bV=jhQjvzCUfr{*A;#?z_>1X_ zx!N42&KX zZzeO{A?CIp^~-*C#vy1gewH08&e;WBzCV^_f|~@$AG7P02-l;z+c}CNVtbZYcVd!4 z4}t?DNasI#h{SAD$e>wW&h@6MR3f?_+_&iR52UC=t%lzvVT2Zt@i=5@hf88ZY5`om zG&`#d^BUCUktj~@JW;5uvj z%6MjunSX2gV%F7gR#-lgjZTc%*ZqXxpf2E}CrD<73yc{}CHoM&V2I7|%LLGtQx!hd z4JipfjMp6Co(oMDw7GRS-4O!3*S*1R3NmlDNk)&WP^~;3J2Gq;h+yiGS<#1gLN^Ft zffu=_i}uicB|Vb~tBqVa0v1k#;UbV+L>gT1o?&C(|jFf@a&jN;-a zP^{kGguV38sh09Jzj$*!>GWi;i$DobmUkx?`P$9Av$Lb47xD&LXmL%2h{!f#@h#2K zEs``X!ebJ4DkM{fdh!pifKU)6+B;$#J86h8oLjAmlgc0d>`f6!^a&ScMZxkUy@>?J zB2kR-Hm-JjtMM`9t>K>&JU|XKnZiWN;3gdT$iQ@Ws}F(r44)OgKH^;P$!%4$w>T(8 z%6>81;$rH@Ojmus#%&J04qz5u1C~fweLLKCQOknaNDyj3^akSq54y)=vW%}R1GwT~ zL)6u=`VKpS`MK;=zLf5iG2D7yRR#oK(5ynurj-CUSeTqLH3A3{sgU`!PtzyGKxhl$ zZPfscMlCA?1j=sK6jwiu4ik|dtQtg$d^^?T*HUiSN{N4G4SS;s^fr2lJP}nxF6jdm zU;!xhgb|rW1T6bl6(C*xXZYoel_8ule39~-a3J6(hP%G!wEo+$)gz#2KU4uED0wsU z{Xk~oT(aiNcTyDDze)yu6`mgXL4eI+j?%c?XKy#(*}4ML1zDJq$##GZ<{`ox^jJWQP;f0m6Waiv_a_V={kS%6l9K3~Hu-uL|2R^icD2EN?$hQHxW^ zFV`Ldo%FG9%7u%BoQ^Cw|6U3wXG0k&3a<1e3bawDX1d+7Tv(`Dv&v?ZNb_vXjEQ|sGgrP@ zigErrr|aD9Pv|sV;t-gQ2=`le6n9UP(O29rJJWqhT`f+i+Mq?Q)bEU-P&1?E`UDwEf>N1@7Oa6mw6>;J~s3JW1uf3t#aaJejQv7q5_UI>43GZxb4M)P?m-0Cg>XQ>APEXT1CO51^14yFs(S3Q z>Ikb1qJ8&ioMtd4alRVNcD`l$qj-o3VbSB;GvLW;gfPPdQfE#`2J6%P&L`Mm=(#bS z8-IEKJLvq00ze?;Is8sK?tZec*>GCX*w*`-dyoK2q}u zD=?lg|Jze7;s7}MBc#WGnI*x~!>6XkRc^A}ED2?E@#G+JD^*$WDuV#q3c52v{+k$= z>{7&=ik{0c%IMO(v;mOLg8c~>SRw@I_S-xR?_Enj2er<{_iH-Z6?RX1IDX257H2r` z`S>R}c^SC&-Q@N6&gFO@(pPcQCM!+d$r?cudAky60UZy*wpgd! z4{YszwS;ACK3J3^J{(I9!HFwT#E&HCwScA^kwgL7*uo~y}*e_gCK`KEVyRQ3@dgOgJ z+-cB6@(iq)#%&m0x|KT71YE_~z_xdV}^M z%#dF|uuG#RX_T?Vr~a73hQ{mFxAhLz5<&-z6~YA0e`bG+H+APjl6bfY!V5wP9vCZNA{i;k2|ZZ zo@Bz&iRkKwgxQM$VwDyr&_apQR{;a?f2@C&6~%4F_gwQ=T@@f=p*i0}jx~K>|G+O` zxi{b-DyJ+bPBk-L6)UYT`08ngZ5rj=2^0mQzb6|aMpf%u<0V3iqp7pgs^csf@~ z%1w(A_vzVdiVpYvaaVYKL7Jw3&HZwsDF+9T(EU@vmKi$C1(zt0B4OFINc@ zK*q3cJzq1yEkao950GGL)dQ9={k4C24_r7D-zSxE+cLM$)8k{!qq+wm3SLDbdL5a@gr5byfRM<#na z^_{(2lI(Ui?0Bb%!u?3qrdQDSleR3u%@*O4Mi`2a+@seKPcuNFX}vQu_n zz5?`9&O|Z$i4s9W&ABgkiW!m6l6MB>_xv~g0G;<)g-NB()+YHW>ISx zlrS=obj5)ljHdpEar1%wL)8t`TNjPypBn2vvse7MQr#$qSS2Qe0` z5FIoJW-%X^%tG5eS*P!0DBB-~Aa8|fwk!oB+e2gsE;9^^o} z1p-yWTa%{g@3G~!E+7qpD;f&=!T=TSt zaEkvvdGs|Qx1(p0@1qY#Ta$ov@4r9rz5T0IBA#48t@^pib>{=#7u$&vZNxPG^E!eV znY3s5e?&%adYl`W#=jG;N%i7jhFQsUvhQ^|^d6-PKb6^DEI%g40m7oAv6s(rp3KnJaWYGA(l|C!evq2*Vs@P6b}E?ZT+ zXY$G*i$4~%R;FL4Vgk9S({bA}EkNQ6RS>cav@4d1CgXefe}*mnWQRr(Z!8*$VDX)C zTkxsHdlG#4v;J~jyr7!5WR7cdwW_PxS`(oj=w$le7hBpaQY$_li*9;Pw+TuWsN zRbvf&YlPSEa}Am zXElk?ZjAsNDC?>N1&-ei(z}m0T~pqG7j+r(c}NO zs4>e(T??oozyK?B zh??j1)pgnD5BgERsEE_{5SH$P)f-7%z>NKWe)jk@bj(y^phoN%A&Nb(CosO*V9Oy! zgqL>HBs(bn-=*(CQe1vzX=(X$cna*WJWA~wgk1_T`&=BWr*hkKC5Hd+fUreB1i0cB zpz*P~{n6Wr09w&?Uv_%&3%crXb`WbgA{R|22y_^?j_y1@VzM3T@J*Q=gbN(><4(zLr4O`i$O*NW)VBtTy{o#-r~G9 zp-@{}n|!-7s^r*540w8(F286BkecwD*G3=13IqJU)XlnHR2^^4s7F3wm#nR?Po)OZ zyok;JASrWE5WXp;&QgR$QaQDjf1u>RXG8pRu_9!JY~w!rIv(QRK?6R$(6oa8e3Qy# zbzZ*CM>?#svpiP*>iWdV3%2qV*q>CZ*v<2#JLoLoV8E!zWRyL*d{aBWR)TpE3t_!s zSfZA-*dh<8um0J9=~v{CAEf=%J}bF-iW_f#aoPWEMQDm`hL%Y#b^_j(C;AGv4;`l8 zyg;l%7!d1$kv~gf_^}2Spo=EX@O1K-j{!@75MnOUxS+mc-CF6TW-qvuJ(#QqXv+Y^Z?_B<Sb(Br z1fh!SgWV&Sf-xROG3TS~0LkCZ)W6AdikGDO#@zmGy^Y%F9Y$&TH0(@FV;wQ zyIn^R7d`!+!IV#)oeb)ZS4%%_n{Cy>mw01TiRnVBnFK>6(NB(V+*jv2k`V=kH4bBh zTJnU+0yU*PRpy!;F!Y zPiD*8u9&mbbQ#Qhkv2S+GY!NmC+Ou}XB^Gp^F}~#U{YoE-(IcKS?&Te3jG91_b~Fu z3)A-Yz>})%Yu@nrUmSRxh|dWFGyj| zGhAONo6b+Ehn45tPCp6>R{$b_w^UY$`CyA0XXTb7W{zVvl$7oF(!1#b%WCH`JRRXl zouY~JN6@L>$28v@vXS5O6;fYi3a!zWB7D=BjNGj8m>;L6Pvh?7;hF!^ukY#nlW7XK z&y{BU$l(G;OVfMfNkaaQC)vEj`?is1t+}p21BO6ED1H~v1M6@3S4X9;I`@xWV)8aE zL9bVj`JF9Zo2fz`M!t&ao{6lxcRaMx%8c1RSe#hEB=nq5tIOt#@z@1kMSva#G_=%Bp5R1~uavx5|4<2; z7YK(qN61qlAhYNPnI74!P#DCfkMs@eP=R;5Y`DzKuc)m_Nf~L?pF|rciN75g+0CEr zp)R_48y5&Uf1JSQQa!iO?&uGz>s-1n6|qCxkIqFyGP-idrKO~9-Xl$|Hrfjuhl-|T zG+C+NqwVUA4Y0`^Hhb5z)hm6nd32UG@t%$aSEpCp?K!hO7*{use}*vVlZ*15*7mV5 z+2ZK$sov#$+h0Gscs|yHr1U#ue=Mo zxJst!`F$OsZfPzy=qp)R%coc-ey2Ur&KF5P$=NRu-yO{Y#fBsJypG`T)mU?W(%hPD z!ngk9E!TTdzhPv8p1&6#K7ib~oER$A(H6vOh!7x^P9oSKXfmb}^{k#vGu_I0! zEku{2Vr$Z923Hj4LlpMQn-^qG>1=>Q%b8Eya=H#!cCPDOqkv)P#D@Ts;_+h5)EBn_ zvUD507@hfqEzhd9m|N6HD@Hm(VKi*GK=W6Gax=!GT3viD)9o@#Z1CXbTso*3@Hkzt1(pe;L z7%>3;UaQMA%%VQ7<9(}fFY?A!Xzwv!RckOj_BnDqd(%v)@x{rtn-9j&<;}co*gc)k z=*wEqy{9*!xsSWbEHV~i3p}T*-mJrJoF;Z0v#ciVT8WT+YgzE_U+4)gzJ=wSIFuc}a+azxs+plME`{tcdOa8QRNB%ET;8tfx9J}rv z@e%Cwz%$TB1wGk9I^l=jyww+8EqCbh2XKe!RGURMo+Ca8%D~m=xH1KBqz$nGL^$KQ z@SG1yt?N|}m?Ey(Mk#(k^^>)-bAtf2nW&mzq*-<55`E`Rh;uVIaiEROh!u*%M5wI- z#h}vNu|5p`ftz8Xskeu&{`ezH-5 zHvy#O3rSBbygK~v-^P}?^Zn$oehC4D^t0l3I@e{$i0Yi%RHc|&DE#z-wwRc?t*;Tn z_(V+6G3^3SfF&0rwij5^)ve9pHYhH7QKsVZa;X&!)P+4PVXKMf+hx(Lp8p?L?;S{W|Nf6x$|y5J_KH+iMh790 zQAQ|AMhMxCajdM!cI?QAjO@*^$;dH6_Bi%lhwRPo`O)%Te`}S}AM^$UFl~Vrhs$CdEy9kML?Kw{I!04p?ygP_tvWZjUAIa)n%0&h4-PhU#G+Yh1l%Ax<7sb9lq z)LVIJWfv?SUgRf=EoKOzxAL10@w!f&jEofMqmw2WaFswjq0VVh3+lSx+_OCOdb3)qTf> z8V)Ph3G5L^$#3s}G5$JS7=qO*oe(8--4M||@$ecE&)d#sAU2iw-XDVS683;9B@J-+}{J|hw}LYI5gXr0_Wz(%?|hWOJqGb<&EQ)y7D}GZ4l#JK}t4 zBG@aJ4{oxgo>`P>ikoUMKITLja}+BL9{16ZD{nwqf>m+&(sP$_NA+`c%2hz9>HqIr8C z`HE{M!TNd8tqhCmC&#U%L+P#F z)!mP`q{7AHPfpY(>)(3QoHaEuvT2oK@jgY9LWpkKuLS8bjs8;iP-gEU`7`~G@=!o* z!ikTxR-YEXwvg7Id2_%>QEM_DpN~`2@r)66Bzc$i^urIQhD5S`wU40!Wa-?$n)9{( z*p{e|$fD{!=kBl9s`_Z~Ous7)JHZNBL|}zf=WSx@zp{_ZmZK3YK~Zivj%FS_wCh!x z!Nt0*%kP2;CQ>4&MhqD9TN5etIWL`b)d=owtmMzI@7SV93Rj*UN(!h!_=d@4DO18u z#5{$DuFEgRht+90Q+COYp+CNx7gkwwknt13Nh}MMdGE~TwNu5%YT`9qnuBis6X4Zn zGr1HZeF?U-lsYol$r+qeGK8n}P6)}h*T(zaBswT~$jhl0(EC8YE|FYeSF-XV&oo=^ ztX6TDLHUS{irLYl!xdM?s6Q_2l72;2)NJ}U7TA&ae=?Ft^g1i3;5moFk2e;spk}&) zG{?)fJJ=Q8^dD*v3=i%Ye@q>$PrSu#t(2B8nPGR2DN$q4;VIIv4qcwd!<_0E+58C# zaDoW&7QRMYQ1kEHhZSk7^xSR~8WfiwjtflB5)*&3cFp}g1W!wQdwP=BQ>xag<0=73 zp@cTN?sMD1YMY;s>^EH2x>p@aC@;_JBQ$h3n?_=&Ig=85Ot5antGN>My>+{QG^ZHN+_2zv?NuT-!HhPpA*?kUQu zMzRK&g|QWiNZUZyEWI)V#&$CVg|ikK)fK0O6B9W_=a`aymmc#Z^mK?*F_l}P?a%U) zW#`P&T+PmCst@1Ow2zJnb}Jr>nHNjUNJ_*djT9CHS>&0qoD{6!l$h+vio3tpZA+H! zB7eLozf_e7kk_ZTVAO;&uh?X^F8J^f_odZm%5|i+?ZQ=hB#9PqPHu|WWeBT5a3-@E zP)pk*!|U1>W`xun4};L(&rI`{ixjC`l{O5%l3u5~8KTvBPx@t`K`vRm zwqu=RzV)tC!lr!0d?COz6ka{9Y#_8=Z3IpC?T(vajkKS&<{`AAgBDnc1<0+ONXCx}`(nh&-5FtOAZ)Xpo+!jf#}A0RX4KAfh(L3ByVPH^*e)$X?n zY|ae(k}bM5jex*cT8ee^dPO?fPXeh5SbF39$4>HTCd89McEwmUV2@Slp6)?e?>2>_ z0J#;Ba7@LWN#DYz^R_Pv;tQ@evbQ6PDAf6EDzMKy zx_Rz)cG#leN~=R2P*mOaLH(SzQ*yC=)kwCMMKxd<_rguO9KbVEpzr>Bu-<|3a3bN9 zd#$=>tJl-j_;c!C-`hh_vm_}WPrat^?&XE$?=cqK!ppF*h8a|4TVSl|N{G@+&0I!( z_AbbZ9Qwr%VFd1_+#v}qSF`#scP+6O z+mH;)C|u`39xBPcLEVaKblzF@&%z)u%Lc!o+8yFbQ{iF$-l2i}0rLk+=|-=-dezsk z){m-|%L%)?xqSskZ2R-0>o3x?U44jkJA6ISwVr$Q0Kz!`pnntdr-v|TD_mn3Zc2%B z%r-uGp8-`G>c4I;RQfPa55Girfht`q{kBOJz4Y^{U4P8Ln8<7F;g`*jcF1yp0v{%{ z8BA-qdFVFuKd9FjD^|gr9IS2sk=o`NMoI5pI$5T99iy~Dqratj{I>o55X8A|*=` z@_Bnw4if~MW2qf0Vz$i8r3Ra|MVSSt^V-qGCxO5E|Djer!j+Uj+2C^_#AceSk#ogn zz()}Fz1xzs(L10tmDY318C2re{VxY%zPZkN>h@ySz_9qgwDV8n#oyl!Ps=9UKeU6x zV(Mr8+2z6JV}ShmFe*WQMj8p_9ms$@AvmkTrs|+6Oc`F6eodK6w#DEycwj&s`ZQ7H ze;Tgs?BV7+%|Lg*yG{T&+$V`gpSn9_KmuXlxZIylnpIMB+E}~9_O#G0)Vyy!YJq(? zIOqcjoEy~3CQoM+L3J-c=$J}wMZ3fmI^O`!mcF$(>m3>;L+Z_EgRv+aiyvXZZihE} zyvuiq%#6>WJ3MP zQ(_;O()v)ax*^{w{9ep8R>t-Br&IB{ZI;g}nkQ#l7$N&L7lR!xPB*o(dXRYGv7F%M zYSQNoHj8O-Uu)Imnre}x?68F{E!7s`Z(gyaswDp`n!>S!+=`z3ihjeR=tk66AHT(^ z37Vv%S;17?LXM{;950%LsuD7A(XbKhKjq#znIi{(1-Pf>?iAnJi3G&9FgOtLJ`{B0 zqunjNt68*7;Q?*Lrq=f`>#~GMqiP<^6dhZSh`cDok4ONLI{hq?iEaI!R{3*!coP}@ z1fO)Y{@7eWZd3L`C6qS5-=ZtbkYLjiYnSnN0t@IIf(0HFdaWbcg==N z%Se}T=|Nsiv}Pykqc<7Xp5u{q4B;8RN3SI^C0<+SvtE7r!r6VdR%N{LFA~>vos6hF>0^8LmR}rUww&Q$JY0I`)yL zPom_ZzJokXe7zg_E%iVoYU}mUTn(`qi4Oep@`xer*e=v7JOB2ZUCaI1qH8B=Zt&pV z%rB9{DqZ@10(rN51?Xyvc;cIOeo0{OZ=-pl@W$iJ5}k)VYT8a{#6OgS!h4nq_U(_8 zk3riC;U_P(S_hOtJ0e_PB0AzZU97b;f%V5>C4S7st4&{)?SsC#(%~72@>nde(wXj} zo=(>Iv3ACN#aUNGRnU3ZR42VyF^JhBN!4B#ruhA}>tJjrM zGB>82$KQtS@`%TSnKVv2)J{8+MA7}!No5@0``GmfmV~tpGK|C+KI$YmH1^t?8RW^q ztm__LYUEq(qOL7d1^EH~oJI|LPt5fxUma)3)AcsxSwXE)PN?!*?!?o;iAbdzaoIkU zu7CG5536Dh2-p7fs%W*K|GE`ybs!*XObqg>jIUm!1hv=>Z|bb|6Q&eGC2gxdK9=t_ zoffc9SP^(!LNe?7t7NctZ6!zQ!@#|%5gyA%>FBBlI|JwhUcHad+oL_;cA`)E2y2-9 zK{0tR;zY}DrX8V#X+cC66Qb*j2Aezs3@^49DRaraaYH`AgsuF{9}O{ejodXAK6^A$ z+9gYRyc=OVZSQ?`Xnu@g7f_?uwN4_sXyXfYIBcG0)vUuNycjpd|11z4P6@)V9=WPl zm*;(nyyEZH%y*Zb1oPIL^g3SJ280l3C?9SP*SWik6@-YtbBCC^+!((42Tw<$qDPQH zKKz&}?O#e;o?88RA}SV*;q844iClZGfG_=inebN~DGGgZr64 zSZsYT&Fgi*Y;Vq?UV75B@kxU!58J;BXFj@Yzeq3yw$X0296gWQoZE|KgP|>wtOOpI z)~&-q!|{{f;%z6L{;S4T4pB~FB0^ES+1s^~O=Z2$C;Mp$)_irVq7GT)=;N4>05yfc(p>em-2oNhLPaX34!=6~T^N{rd&qv-x{ zBo0y=W=$3xGU9lk1D zYa}dt`n^|0XvvNDn81X#9|+2kOzw~0mow(yZb`Ac%zolnwfQWCjxy5JmC*Lovt-4Y zq=+bA=NQ!rKR)!d;Kgj*Jl`63cE$or$S>C+A{+-$V9cC;~BHH@@QR&I%k z=3Zov<>(@tBLGxmy7lMwZ6yL0-wCLRU7*;rO2O2^6@1%FhhI6Ls8 zU2MC&56I=SKERKqF;NGxS0Efy6tf1Ouza+@L-d#kCsWh4T))WB^u=cXeV*j%NY7n1mcEsHP4L-r z-qjgwprRn&n_KU6W44v!e-@Y`N0Kftv7+RwBs(QMiq)3o&gQ5Qnpa_Wy7Ayzm8WzU zb_Ji%$7su#Q?Jgb%+8jK2h)?AcQnywm-oJgd%g|Lj z9zK0#oqmFL`^Ju;Zng6f)1c;ZQtb!zf_p7TsCM&IB0xHL^*DwDMBn5g`xven>gCi? z9SFq{qJvBeSpmA=dCn#yY3ZlW_i_Q}U<&RF{(DS@4M6)hD>GAmqD*N(Z@*3IrgzgX0Y0gFtDv1k!I z2S(qY&s8n$iioyB=J=Cy#GW_SQ_efAxgjhIDe1}^%+K(phR=O=E zQTO!qlhx9vod{~w@VZ22E9n{3WKt4c%fWmF_ip`5R)^k>+=jYvV8nR0N_-Y09q$jo za+pQY_3nE6>s!kWhBx5Y*Flv3s_v4bo_V5}L_UUI*e3P7Jd`^To{Lo5KFQd#bnOFe zPK1aMK;bv1A%0`Pllk$`4cApF?S#+uPC>UVwo7}CHo%*LC0IzkE2XCoes4YOV=!bP zUHWBV91;Y$jO_w{)qi+cIxV#jFx*}*E{23o+qq_Tt(k&&4>mW9P{~lVl7>?7a2TP= z+A#8xBj;o<^u(?z#ue%TXFdQUAG`OydFtK-w6;uP0q312f_q0JKASMs052M(3AjpQ zyy5%Uqc^A-onMv`Yw^8QUqz(K0-bn)b^5=@H%ZEyfsz1^-~z*~pPZN-e$g!ZG9?7y zNk%5m%5I@q>Du!|N=J@A7t&h{h!7Z%itd%`Rbs*2e*NR)mgh>Aa5~UnUz2OJpLIam ziU>Apj&j~1&0G!0%M%O`&S5@$jr`K|?o&&&g=qTB*HQRtnDG)KlmEOP!I$?5ABT?9 zb<&5b0lfpIK(+-+G0;SykizJXANS~iHW^yXBzefbL!uk&urd%FrU(N5^(*8z_ZGXQ zCLEMR59y$~ahUVYTexWG)G8_^JB+3AB@ee(u{QEkd{3STx0f15l$nigc}Gd({;EgH zcHz<9dOpCU;17XSG%3s5LT@1RBJAykAE(j;SDkP-v^x+Y$a1>Aog!c3uetPli$~$N zp8YyUaMK3;Sug4LCOPZMo0s|s&8%hG#fA*~+3|iQGY9)_*Ts5`&=P33h9hzsaaUg| zvEBz4|3SqE8>5!v)Fc2_e$p`UOZL)+4zg)CS|ujPq$ zd#ax#kp)XX9@4XwTHC&XMm6z6rHiodE;tl_v1BqoP-wZjAAlBd#xT`Az+Hg0PnXSE zsoINuVT-UktmecE&T$Dmz_P!7!__yK+9qe~x0(X^CZrJJmjD3PEqw5PUFp{6% z?)T?)VN|R5kXsX(tett|rfrv4dfBiXec#@i7r1E1P0Q_IE@7N?9OrOS1UX7xK!Qpc zR}#hc!Q($&ql%4v<7KgX)C527Btd=CeyfWUIlO>3StB2()3^aXO=ym4rA8XGJ1;T_ z{$x#u1*eb({}-FEjHRjBLl zykI&UT;p<&EmmT9KEKxCyv2EvxRZ9I4#g|{$!@jywv(f?Dkz9f#>iCZTWjJa%sx*} zwU8|X182O+>FnRRT<;zMs*3f^4O|kTb0t+~0uVPWAGJoGx_UriJ(OINoi|5tLLk1! zt-IgasA^Y!#C!ps7Rg|J&lj6gZCqW6@+~zn9!sh;?|o8MV>9;@+OeAnyCN@Y{M0Cr z>Jm-gOlA23rH1Dea%bP)Kvz7tU#{x%2o-4XCcaq*uOwJn4`cCkq8d$AKxD*fI5cP& zwF`gZ)-LW?x^Wk({fnM1)kc9F&c*_@>RH}}bgd=-mFy6iS<@+t?cBy%`xp$r#Phjr z0!!>B!DI=e$RxS!XTD0qfu_x_3fxnm0>q_%(og*0)Y27}$ zc7jmNE#I~(KnHWvaw_gd!nX9_GRn`qAF$UovBh|Y-bb|gnZB?k#K|Q0_0l{9tcAvk zuR|4GBL*3q&Dg)&C=?T%okLSZLf;1#9iZ^fqH+J+zN2Kar)-%&@T;n2sUR403_d~n z7T}POwz?Q|^ezaIog#YJqTco}tK)7^B(mL(S^1Wk8P9FH?VhjFL3ns5^ zZzc${A=BovXoO?4qEnqXJ_JoG$V3XWKZ!(5+c`HPMfTGxwNJk&`q9?CpwVGV9_G3J znyxKe`E|zZ^Ss&jx${XfeZ^F%Q$K`aKs^*S%w(g*QirAB=qb~r>)T8>=0X~na0Gc( zstQ1j)bLyX#2P+NSyi~E-rn&kA%qf`8!A*IOA@~0ko6bQ9}Qv436bWRA$}Gb2?a)b zpF*&p6_zRe=1tr(AOmWR73f4epm2wpp+*jrsKWaiC#9QRBKHF6dh?v!=Iw1*okiBR z?0<;kt)RXT2a&o@Cfz^-v(jt$rAG6G3|O$9^>Xspn*4UXI~Eo3C^zC)&pRZ!&{1xF z5jXQuDL03d-kYe6cz)xu3LsyK+uQ%Ry7I(Ev2pSj`gB*gXiEWyGykWgMIEEC&zSO2 z4a8=@PO?*e3S|#gzw2w`HC2>!{O(Rc5X)8_!O^fph|bT>quvcWge&{J$}SxnN`|Bn zYu7l$LD4X+-x_}FP~20iNkgE^0ScUSB{s@A{jcMUizgn$|ANa%$nyEO&3m_bQ(S}B zR>qG&>7tcA&BXyam@)ONS&lDmq&ptBtpAlM^dJtAPlYpoR!1;bF88&ECLY-;imucG zZCurELxTBAEb z8DE{&a?g9OXql3S;7Q;Wv$;M!gmh+dAA#mn=8W`6HF2!p=TvH}cla*RJ)g(JM1db+FB#zp{qMMUwLAP*Rqsb~1NbP+I_FNYG-P?GQqQu!gF% zdY)D$+GQwGR|~XSeFR$ti8$=i>~6#ebgyLi)DIJKQ+Swk-srL7oY(T%8 zi#|}ctn;coZ4d>Lh60}!-4degTdsJ!w!+zWZ!R~sVoiCJq?*bUnij=QL+adZQVEE= zg+@Nkh_3C~07+mU1Sv3yFnIER82p}U4;B>qlFNkbSDI4t$}j&&!1G$ex+{=Y5v5rA}^6 z0X;k)35Lq`Kb&K`@xr$Md(lzh2b8>V6q?3Sp;XssL3lTPp6<78iUA1-F0P7_Yd8sq(9yfb;f1c}GM5^$vLqCC8 zG_p>qEYQvfs_it+)vMre8a|~Fht5lYob>QQEJ7Wqhk$NQC>fG>x#~c27a)6i*Gb8l z5XrUM!utKUZ?E!%>H~!lid6$f5+SRv!|y{49NP()Q!js|1{Y$uo5VaC37$HyU5jrb zjlgH19J|NK^;UiXsnj?bxf_`G*_I!)-|6Q{QzZ%XV^*(Y^*5g>d;}TjJYwP9qKBGc zY=&$c#-R3l2_&K*Tm-*|LZvtlxFu;JMEjyH#_EGq=9mKy&k=K{A)INZl(K*XsX`=@ zLBK3NWXpZLjW-hyq%HFS3_iX6a~UW#%~grXq+C=LVfPSBW}Kbf`&(Du7AvJ7QNZAN z_8J39>qUuMe;2`g@GW%?s&d|W07Wz6*t!}>#Lia%qq5NfjU&rWbsVpJF1o&PLt0p1 zA(4{l>s^ry?W1G`x{m1!`IJuBg(MlfvNEmsd09HWt53@heX;$>XZWoG78VvF9XQQv z{s!sLvA-E#h+r$FZfj;dqQwS96(u2Gi}t`Qjq?V7%fce2VCcd>ZqvW)gXL_G=w3YY zQq6WP?z1Wpeb+(?;hpn%;Ph9e?Dg)lG{H>wE3MdnCHW(a*8;^XRa^;E}pdf9gY{# z7L^&G5(IdF-O##ugq(c@m%}==^#ZoV02ZQcKYhQhR{cI~{O1=UW83)7Rn1ipwO3wn zF7|S!$Lj-l{x>RHMGCk=X^7DCL%X9iWwh}>s(*pmh4GoQAQdJUItQ8c6T z1rJ1M_k}akMqLPn5w{A)ju;4-zZn0D;Y-V3=YZs#ACY>8+(cIdm|E(`SvgCYyLHEJk zJtsKUkd*Y?7X!)1U0Y5MtG8DM^EcQH8U_dEs-xn&b$kojC5f7b&EvFXS&A*TY-s}d zX^cc$ur}0m7*!*KK~KIj0pE;kh zCikkA+4NdCkOl}~A;^7Q{6FsGE2qgZl-F+>E%#*}q9@a<){{U_5C}4W>tNA)Gh`p! z_mH)_i#YEM_K}NnL2}y8^Afa^1*S zK{&m;v{TPCsN758GcsEQ|CGP83E`dR0TK?GOWY|Cpnt1r-=BZ3dfdTWAF}Q(?z{6JJWqU3xsaGWZk1#-)TC=_T#eCK3gf%9F3UYJrH<+VvMSHtIii zNae3ffk`+iH&;NT}aHEZ06{p08bvC?2 zn^}*l2juOFz%4kedYp1=d}{a8xCjp2x{Y0QXBQFufu{R27u_FCQrj+c3jUjcRHdI* zNKZ{)>wmvID*W{Pm#f9b#qET&bgdOdINNT#IQLKGFcS4Iq-o^qob#&YVb39w zW!jIm4ed5druGP5-s@k18T>}XTt$4W$}dDuv+zcuw8k?GFD!HAOPz2=Ju?xyWK4s) zGZ>V7_AxvAa3DL=uE{O zv>O2Z{hJ4+2&|?p>i*?gHPmBzi(;d+PtYkp-mPewv`FdH*Dvch|R1&%C>g@wTGSN4pP}+ z0MF0=?*RY;d^Zy4n{(njvXub>e~vL$mKYA%tNtm<01iBM1S@_-*JoXQIAw#6fmS>V zRxH7B{||<;%u91*OQf+8meEbg%!UB6niq!wu8*-LGo7a6vn~n94p@g((WA)WPHk!J zs@=WVG4`Oe6hSDapFWMW#o0MG$70D+|)Nd9J_Nms1{c z-5ntktq&^n z63U+xztlL+kD?__?Qqbg<_k2`#d#Hm2Y8+#;?tcv{NJvf`DPOR*J? z$&AcXF@K%)_Kh;19x^%HkCAo+a-V;t>yK%ode*(5e0RkV$ny_nZzuZ=LfNjbqqu&< z4XE{2DQ<}Y>hyGy-8+>!mv1kBqoEEILfH>7_)_Fxm9`3D5y>U7ElH;g$;L zZ+P<_igddRJ<{ZYkmYCwu!e4vyij0Rw7G2j6IhW|WEu7a$249+X4O>rh)wcaT;%&) zul28jy8g|tSixr@`H00r!YKz5 zP_dXvMCuy#{U(Y?4=EbMCrS&RdwaoFF*hE|eZ2_=KQh?XjqaI&ci%A)+S%Ai6-+mj z=ZyM>?DNH;QR%xag*3q|5v3#Ih11iIr)kD42lKT1|8KSn&E-5nKu4#?12}C}&Kyrx zxkWR9Mc-Z|Yz75+5=HxH%6)1zXhc&QLG2N#j>#17TL5xhBz1V(lQY{PWtX4s} zu)cg<39)eok@w!cnex|+P`x*a&FY|wMW2aD1I~j@FP+{MDbC(w0C`FO&2ir4oF{JQ z&rkaGgIpm$Q3qWQ83mei5>GfIca-~z}T2qSGEPN?UTqK;aO#mI~+^bUB7-gsKQ!Z zKVIzAk3U{XQ4?z<`^aDz>G8RhSP!n0`l^E%IGkJ+j&Fv=Injc>$?+Vt#_>7tq)m{X ze`4xcC!ZN=M&F+i%C;i0W_%?ZY2sB5$Gq!c)~)9Cw?&Uq_a3>Mesk^BU^Q zG(unJsd<4&W%)?cKJEDA=D>7lJdM0jNDFg!Sz2YZR@GwTJazieJ6$ApCA`B)gi+gH@bt)vdAOu478h)N>ST zltt4N(Uyph%DnSLUM2Tp67tHCZy2>ZQ`pnD`VWILF&0%dv4Fw@TbYZ2)_v7#yMody zV&o+cL6yZwV;1OMZo@YsuYZAE*4+Z~952$7+tyH;EI+qH-Q+@at#|z< zzn9EScm#PFODKXt)xIpmXEF`UG>Rq)C8#@sj@H8muUmJ=%Hj`Mt&-MtWbemU-;UP6 zcw!skE?q7kxgv>4^%A+C$0&2`DSZbZY}G@W|C>S;HII$bcRln}r8R2G|4EoJ#>`?j z!17+5FRuqb(oGo(Zp`$AH}6ZI{T8!MtP!E>iILub?EaPRHb+Rtv6xY7&`dYVca*HU z-d$rpd|!>`66{M@Pl|C@QDd*rED|_wGj(c2q8AK{WZv%4vU3VnGnvw0w3i;OwwT1| zdY5XWUFb|EglI)FSXGwJ-zQldFzH0qKAx*?;Rf&Wb(|nvGQEURKJBm^w8_uqz(I0* zPXRrulu-}zpup9%2?}VZ%5f+O&rzIsY4jj|fMC2#lkkax@p`v*FPv|9>d%xRUb=;t zb7VqSUdwxF1qW<^_vrVex05GTEJ^b71e=X=IiDHj#;j~JH( z9Nv2nduwvxe0T(DxXC$?2qK|1YGP6i45E9Ds2%~01XXg51~s)jS-Fe;N9b<9D5@3I zpQoFxUoXKVzS%%bu(tp){1_IF zmhZ-8>$yIl{r|dk5SfIuKiT^weyI2 zGvl*^w?ODMqDQcDbWn3sO#6A9YrTFcuyU`gR0GT7c{WUyd_jbJYPiAY><-JUp$Y1S z`c^%c&c}u@0W!p`QdM;A)seUB%3$=?vl-SmMIE~PkI|bxU9L)*9dU|J9tSAXNg#p7 zv&=F<>EL&%nTFrhomQ;F?}$a_<$<|BsdH#<@sp>nif{|yPVcw@s_JmcJ|Jd$91sA8 zWcY&v+D&~wb(MEl=1C)2u#Gv%HTH+A!^NY-<^wr4!Zy~iMGoNSMVVUhM58+%)T)Sg zRy%$72(_CEVO8~q?l}TsFxn^A#%?G2$W2l4tY0e~C-SqlsMGB5;o;7`v9png$~v&o zGYL$2!3KMBy10K!t=Rimc%mf8lS( z4#x7tg!B}lt>Ds zX*rLGfRQ9Mm9({c z>aOi$QIrtY%VzKgO-68y{iV67=^Y{qL*E_9&VF9wL_~f@PQ^}+5HgC7Y6*g$^xE@0 zgQ$3hz+Ngy;QQlA)65v$B4?KIf5`B#96Vz6mD-||S@vQ1vuNaD+#AhbJ~W~4O<)5A zt-Qx@>1l{g0n>a+1XiOG`bDwj#Y%VU7nkh_7iyrOUm7#H=X(!?g%^Lr{)_X0IV6v# zrQ&;4HkCrCRV;CQ=9o&#vOC0_?N-YqSt`7kgiEGU+1X~mZ}6v04T}N3?qwAkDQ2R# z6Li+0v0xjf^G8wULq2Gwx{q7pkdW{t2nX+o{{P=dJk)`PF*jQ0{uM!+HqN;dJ-_6< zPaSdn^R=#`yJzU=I&-0Y5AmmKs|6>wQai!Z1h0hkJT@I4hl@xea-Bf0WW2qbNr^8Tel(cCGy*m*WRg zR<`VaK*>K5Xo=tO>98K*O0TS}l&t>oK5};)gLsoRkS9os-}(T2l%98UZBeF^KRii! zM-Tw-?yMwgPuuh!N*Cy^fzv*>N@Xni-v4mMQ`W4 zp0j_Y79lztwy@W3&k%^=iwR1kZivg1k zvbqMrEeyZDfSCf}c<1?v;>O<*Gmn?AxkU!{4w3izDNCt5zZnVZo5C@ z_b$q?{d4B&$x*b=h>e{+@TyL==t*onRi;3h*8r96X=zUExT8N8Nn1!Z2UndD4jw- zJSLLa?3^!mHz0p}73X{;lcbz0TsXsJr(yNY_s2FL$|v0D(W8F&7IcGac+59_!LQJ% z4@tg=gPWo3e%QMlV}M+u&~^obWO`Max$&&N5-B-W%T^DfV7(eps1oga%hm;zSZ3F& z!6dZ5L%F;{4?p6Yd^mpVrQL!=*Wvk_Yt(@D}kzx~MzUc$KD#^AGNL&SmY~?09 z%y%YagW6b)=3{$ze@pK}Yz}Qa@x;Sn$X~g>aAvh`F`1p!`QdClv-dvzh@Mf5Xi0RZ zVcxHr(VIrx{Bx+$&xl1r`WVVLhtVb`X_R+S881{+x|45b5PnomqmJ67nWayuzT!{H z`{*~5*H+t9v29_2XoF2a&vB|BLfX>wMnL07Cv$n@hv$Ywv7n%!KJayfwZn^Fjh)&iQZ=5|9W}L?U~*Urbg}d6 zqj%6D$zfVbAgNAyh*J}={HYr$v*JNks$l#{uWKfexdeb`RY+Rol6v84Q>9om-%@T` zu(px@D6OKRGTU>=d9xzo>cPQ5GGIwJ=?cEO@7ZrG4_(T>y-Ia7GU5IVY5!-ke)%PU z7X&!l^>U#JE45U4y>K+=(&?I1PQhIkf&1FjGJwAKj)zuHX3k_rs9u|zB^=bT~E*rhWU_3&pc<1wy951o7 zD}YY~jNn(1W@Kc9X7*180?l!<^gQ2qa`SLmV~|-_=Gdx zu4rICWh(`kjCBJ$Qrd2sC#BGQxVJvRqJFkSb*eS$z7nC%H*C@FV(!1c&G(?E@T;KY#-Pnm-G?0)ma{K{>Yl>%M;-JLvj-bm`(Y6vjGQ;Ez`yJ+(A``62<-Lz5v&JUdk0ihU6CG}RKf>~( zK>j1iPmU7vBKLTBqGuWe>35^uPj7MF!(3i?w>q#sajOeYdoms$0bU@uaAJum`G^@GPNMZd(ivr5xUrm+?2{MULkCpGxsHt*E241WR0|e6fuqi|quPfIOVFH)S<3B3zr;nrW977ZHu!-EeJ89UxGV!s z`Z(D`fN?(ynk&Uk+eK;LbsG2H(I9^0s)VF#jZQFan5bv~u|Ir5d!&t>*jeh>awt~a zCz5iDaiXv7DtpbKjJ1m~_U`x`xh%^~mr^dN;@WPQzI=B9@pNT~+<9GX`mAYtG*&ym~ogf~wMZdi) zxPi0ZT?39!GLTolPDsE0xIzA%+YEFjLaCG9vea_7@PQ6dwkH3zE6Z;u`^(8HaQKEf zs}DOEjs~CTw{@xezfKAG8P^reR{2>M*Lju`F`WZjZ6j*6l}<3o|E%%a&m^9;=8>7*t*P5OXGaE zg;OR_Pbcw&{nRCp7UmM~Y0fv6t>z2NbcRPBq{9 zIObfjOn+pyd$DscJA}W34hNOuKhNG;>vmFW8cvq6bA~pWH?zgzVR0bc2r6NeJM$D^ z@|%>A7VzHusT|eT$INrG%(XFXk!@HRc2svCeFtVd@~2wP{$mEVzZVsVHOp!$bWLxH zdZy8TmwCzKR_d##v1S#-8=5N77bMhyT&&ds`at?1XW4KEPynbf&92I}dmWs9x$BD` z(r%YTamIh-^5D(7((f2np>&Zt=F)=#f)b(nVa~SLp~EGE0mj24w4;&`VrjdW#{{T&OxDD?bCJ>P4&%*GGZ?UYkgGb7Bt9ewenmCI5R z=d-x_N!gMzE#Lh%QlqF`;T}`Z;~1knDF|HG1u=+ec1o&9c#%FHl?iClfnuS2 zIJ1jBi=C|H=Ylid-TfRN*di#Ym=Vk@@fo{KcWcTRp zwenSovZpGv!ucRFRQmW?OTS~)KmOgRY;&K6Hmp%@sb0$$+7$GMdTba%YTidBRuejX zeSH~}kMZHrMo~jjeK34xP7i$355c4=3EA&GMS>Rn%+%hZN}VpUI)pDYR6JAtts`Mv z1_kmB>AIild?GibG|5thBrosRV>y~ivlW+LH(m^2n$|?0KMVhaH(abhKle?UWis&Q zCKnc}lmf(ZBo{XH?EGOLwfgq&Fh3Bqc|jgd1fsTZXgy-jx(n$2WiJQfrOCE z*9YN~DE6g32^9NN{ZBv9>SiY=v-CfeGkQCVtdpb=QuVL?pb_S{zp|B+Y{%k*Z<$I| ze-J*0{UZ9)f0^I(t`li)_a>GbwZ=jMKL zPcF!YJ{!3wy?FU3;mMWWiwgnKb(&OiY`J=~O4b#QrvXD1rv>*`V@$UN1B56QoR#OR zP@apHV|!q4-k%m#37sHyBK~szb_%5=g5CuXkh8Z`ur0fTFeVhnQWy=T0j*T`v(uhJ zYCzJO65!rG^=0vJ`*^98US`cZVkXLdI#)wNPIynSX%QUA_T=DB*E(7hyXA(A^fOjd zkzp-g5vn>9V1Q9`>4iLEn;*bX(-&N8wll#GDur~w37CT3;AQYlqD;hM?uV03UkMYA zK2JbeMtvD7sxLfWVFfjaqn>S4Oa;TUp0uFfH;OAh^rU%QcylAjg3jP-OXq^5`xfJz%d(zyIJY0+K&sQjH5@1K7WuBaW zrnSC1t~Sv{Q+`yer;GVmLYZRm9c|%~`@VN3NRV9&H%_=~Nzg5L^b2%Qj=ApktMk4V zJ;C9eHKMJy(v;2{>5i{7Xys4ivY?KR@Tm-(9(!>2=d(KJ>@?kE-1;{WiHSVSYn* zCgyfy7BEBQBp@Qa=^Gpj>`V|11pRAA5nVR#&=#%cH_++3nOt7}DuD8K(&EcPJ~aU$ z$v7k(E~)+)MaIk%#yI^Vq#a^c@QNuHx9Agd@~wE9k|lUEO$67-NdCT{4ch9G{hgVO z$4RJQ{$aSePEmf;g#c-H4^Y8f&V-SqR11qL|p`j6oz>fIWgE3wpIBg*RTd}k# zV+*Icy83s`;y_AWMceDj@%C4HIxRee(y5UaC-L**aWOeZONDRiibI^lV>n-7I{k$f zU@5@_la5=*ZWK9c!J~XBc6uVJR7{#wN2R=1X^#?qny%abHu~DwM4`Dc33~DU z+wJa!dINHP=b?wVlYE^P$bNsPoZ^s!>Vl#uyuPofhJtaSM2Uf;_l*Z194%;y>3wWP zyGR1B*l36zVa!3YF!X#foAPz*j|^W<*Q$ttSTjs=&!9hT&*PiR9ayE zQHX0>toZlBkhghGk5`pj5$7= zjh#IQM}%H;ZxTf8ivno8*#ZHCQ(~q}&QyDjD*Xc6lk)4oB=|#IE$F8>mo!@B!HA+H zbB;S8-<;7##N9broI9_fI89&ZYQW%V|$i#0k_r}xF%k5d9x|s2@@q%Q6%f*^ccBpkRBR<)_jZG zX%PQ7oAdYdLHq)qCey%4vVSGJe?Xbg6cuJ3w!LN6{W=kIoGriYB-ni@n#dn_N$|1> z#T3EQJSqIzLY8E(*+b16@lC_;REE}SWSas*49&mbfbu4oZ)vCSCpz?n+$|eC{dDAJ zKT83pM>BcG4xeU0Ka1HtPnt#BA7HutAq}2; zeBbvw=Q=;V{J}gk_p|p}d#$~0$E=_RcWU!Fnu>_pwqt+v8In>iPEPA`hII*K#G)SZ zm%0b2%mY9n_l=%1g4IIBTD2VpB$DM8M51@Svz;0JdLrnk$68|JqqBrYlZULlyCzIj zADdZu-vtf7-e(BG2iH1T@XIHU+C}X!10_@vBoTLCDPbk;2-uG?dskZg zg*VLp0Dh4aH8eZ|+0t?+yK|2LL`FdW>n&22;7_~t`-A=o17O*KC2woY+jXsPSVZ1k zq#!woAA1o|EFr`UuEw2^=HOw@~Z<5;@bZTZ=&`@FQfNLE$FLj3hEfEj?YpLOzW|N1> z+?wmNU6m-WE32dA5-GkF@$YDluhmvz{g|i@3=vn77t_RxzoZp}=;X!S5hy zN{V27JwuPZq6F{cefr6oXNm#c%;Yl>OJyL@JdkPYlhb6KC3~|yf0i|5d>qBvKt=TQ zG{k1>z@2hCm#P^yT~_rheSUzp^B zzSRBh?Rt8ATERmS)%SAXZ`qeYnaDnzIGNMqgUK*;P+IcoIXBY&j_z9r>}8Bw?76pQ z@h3Y6sgj&*F&u?e0*qgSFHSafjTmH}G!a-8?a6*7Pa*|)ze&SAvZHwVZkBuvd8MY{ zndFE?{TJAf@nvMp}r%>44`;6ax_+BzG+`dMAxeQwu_{*#g zi2Jj-8Y#iR1v#@-BDUQjlyrt3|tNciN6&=l0*v5pGQ{ha zV3f#_b)MTN^IpLjpAL5>)qjmS>~5!P0&OEt%TAMT-m5Un#K#5W7ZOwOZaAI%nuzM& zR~;7gnL%+KIFTNsC&-j#pS&_>9eF3gjNiL?BbNHJWNy%Xcw|cjh_IU$0 zI-=C!{-NJmq7Q4LeRK5uC~7?i9U6A4aa!mXN7DEqnM1~e`ppVOXC5jxyd2VAhZh7T z^v(@4J+T17N%Y1{t&kP2v@~e&fs94(p#x6Ec){{%vQRky$HYbgcdgMKUiV&lwT#R^ zmkg(SQpfM;t`xCivJTg;?rCDzAq6MR0$rHD43O&%4`5HTnN=b&fg8Ls&A^O<{_eS7 zvyT3!D&h`_3~l&+=P5|z#eZS?qt}m)$2608a#iBL zGNWDg{(XuTVe5Mv8=La_`=TLRg5NQtjvdX&QVE^#J-d=7W^c=0Je<;9$U=OU^Q6bj9=1d0g4*?1aEd-{BWA}n{AL> zFlN6ax;rg0H*hA9cpROc?~Z#N$VV?HC&9dZ^+TLP&5=|>dVEKJi{)QhU zr502tq9fa69W^nxK3R8qH*3}e{`=fYgoMLT=@~d*N zOJ2V`yg|L7V$j>bg-7QR;58uZO4xU?szd60&-VVIN!It3bb7JMh%cQ!@!r`oz_Eyc z4Gj!9re`L+2p)0mov@vFzU}K`y7M zr|>T~#<>%G``gj7llBK}*Xqx>(rc|QA{JVaUpY6T_Dx|Bcb#yYW|{9E#w2Zb&^e275V=C20W6Vuo5G~E46fPv&`1Ody@8G_00Bn>)X79(02`O$blM?7{sjZl}ILf}ys zM_qOo*to2J*A7r0*ZfuGgOTfgyqBEsD@65^lI@J?lSDM&9-d{Tr9`6hFM=rn&T#1G z(ee6bG>D|B{j4XQiCFfe9YmqCZ2^B8e+Ob8;>Dy^MI_)sotTs)@j3XurLKw$an^(* z*%@jVa`LG1qd=MPQRJ{LV8fa33~S`!XYMRh47e0p!2jbctPq$1de781LUkHgP6lzQ z9ESV*_fJ2oDO@Vb2X(D}j5Q3kpRU>nVE^t<#Q1OjM~`MvPf>Xrd132Ls zxNw1icYW3tj)<1K-l?YQYMuJTYA~*ze+vS$TSs0Zw&V2kUPd+^hS*S-VUHUdOpat?8;?&~#j;of z>wt8t7x5Ib%PC9^X)Y5kxFiN-PoDXYesx)J{OF36X*`p)GSskC7yk-zpV=?)l%rTH zyWAN25Yk6`^R*|gun*T4zDw--p8r*i0`^S$9o;#~;M)r4p*{Wb-j{Rf(&QpIur zw@j8NhujD39wZj;~-wB^mMD2F&tJBwMe!fa=vCySF33DYS0~cDCf{^%p*reVJo1^(JIFHuY-=Jto&a^!U0x}lzi1(8GrD&OrQ)t zK!O8FDYsRX2~dbbh@eZ!kg#zGAGQ-84~>HC_t7z;WDAiRo}_iMx?s*{0OcnsZYmJS zWS-M4`4+V4pARnAI$k+B9;>~(J>OwTe?Y~^$yl7aU;5kGq7#Ph(BfRY^o>JI$OU(N z`Z-+z1{`!Q7V1)x~O8=b30CLi7c$w zj)^(xzgZjus`z)0y~)$vxvNi&RI2z&I^l#Zmv6y{0H9rLhOW48grDhNmWS?Yz?^N> zyOcNy3r}Pn2uVy2#NFVnBo`(O4zp6jLRpMUWx-H(E3biZ}7It=j2}DCn*d`iPJU;~UHTinx*vdv^fhU1&hO>kVs?G86Q!nR{ z*XZA?){y)`sj)sbd|j$7ws_kNq6e@40p;;T77~Uk zhoepIwp(6n8ygjmNIWQ;ND1DXG%6JD7XZteR-(}tB^egv6U>T zT`nEs_1^@Ngwe@t7Z^_lPJtn>l$^vG{AoX;nEAH~Sfe2EeqvesAb1LxX2(-#u}2zP zWkV+Cy;fo>8?sS_FCm~BI}4wQo)thZk(N)Ff(H#ls?3*ZBZ2tmGq>1JYCh$wfGca(@!QB&1z6EL_Qku{;=E&zMGKJJXYm&ts-RFT6{{f zES=!}=I=yK9#+TVfE?8=4*^9V9CXg;c^nay1lLY{(Q^qvNIb}#HJCq8cYNR=L*rp* zV!?iaJMPnFzb>A2gEH#@;Zd5?h(hiytFY!l*3If(XUBTs2NKKMupXNx?GW?Kif6nH z5P*?>aiv>LHa-6t0X~P-!aI`Otk3UanY+wj>$-ml01k0Y>#SjM+>Nx)iHc*B%ptkb z9(pQJ`TF)3LGJj&s5W*kF4EA@PyuP3{AqLtTcKJGv2B0WVfVBfVY~1C9t?&&uaT&3 zCJ1iGHxsa)zj;!N)xBXh>u`^3C7t{|sV0V8vvSGlmp=s0)PD!Q61^>Hu#61&u%6iH z-LG47<`w))5fKnESov2NAz@s;cfroi9^awW8%t~Rh8c$rd@rn*SoxrbmXZhXgHoky zYWlu`L^)~zVbZf5oNg)j0(bbC8D+ze74oZb+7KR5Xa`+drT8s`TuMh9t!x6hjbUtz z7D$3>^&w%3NYquMPHL(vfL`F|X@JJ#LK%+_y7M(BI+^aB^wFSeF}iag5pmZUJ(NS{ zLva%eOw7ILQ%o%RV9JZ2jmTcm@U0_JD97;Q&D;C37x_V;^o75=;+RX+nVay>heJIQnP)H3b{y;?%JH2WObJ2kWijGId(d~&ZU!5!a zi5N!a%7Ou2+eERG&L9Oiyftfkb#1MT-1A$9Fig3G=>AZhUA9XhuPfFy#OY6g7nGB} z>g2i-@)0qnT`9$^C0sYe74zpM=LTCB7vq%LKTp57@{6o=NTkJN{(d(W%G`x+Zv%(Z z3gxj_$wB2vWxLGDD80P#*+-o5VUedagMQMN;vNv%m(DVA?pdQ>TqA-I{lH{1Ub&gY7C*XFpdM`qlTj9x}W1tc^+|1bD2#=w`ScEBXL*#VjFw6ty2#6{)G9?j> zQK-ufF-BApb;bgjmrKY%57qXL`S&LjT%L~5%$t-K3VBLea_)#beh6E%+ZbnN)RAPW z2JcVRsJIf*b0?||*9hdwn77m4u6M{4J%1>ADG7BLXP;P>mdFmzWo$y8Cwh74VB43G zEfCkZ3FO1ls;bA8w~R)k8M>1*?J0>X+LI*QnObu#7r9~k&Nvy z1OjQ++ &6pK;lZ$lC!ZxsW=52gt7_=p~<{B2BN8gxNg$Q#V}qt;e?f`lfKxRSwe zq4nbh~AebT?{# zJ1zKd?7$_87_?{sihO)lPqYaE+7`UNJ`XJ7s_4sJV=;MNN0^4{n3%jXZpOd}#KpxO z|9h#){A+mHA6d>gYL`Yiq@TDR9fF-2p=6{WYx5Pc>g~I4&+oBrn%=Q;tC*Z$ekwnB zMhj&uM7vcUc3*B9L&@jvGN7c(lzlgGW$vhDVy237c<-t{@9uWvrPF}Sk7qf@O=uK0 z)ZeZwiW?nCONTaIcay+>H=aWQR7WYO8KK@3d*JxD9FRy*8nCHheJ$m=TO)i}A75cj; z?pue`J^Nj!R8AXOt1nkBPPV^w)N!cH&0a_UtLKq0&R;q(bt{8cckKdTpCaQ32+-gH zUenLF_)I$sH$ZXv5I)%&-kLQ!JRdIBR_Is}$ik{>XBC*@8}0Q-Y*&@*&j3^7)!m=Ej%THOA-<^rvdprB;y}?+xte-H3F5<1RfiT4JEm?6* z#QO-`aXy}dWvO-VY}ERnBE1n-C(~KeJs5nL$IW+u3Bjp1V+BhL^BL~=<_b+*E&klP zZ@~iI%_qQyUxSkI_D(lWb~k~0f`(r`1AM7D7!zNQr%N3i5^17fehw;-YVFW3Q>qnb zKu1=LEC@T`qx*t^6;m*}gM)(so-698kSW17pVDKBJqebALIyQx^T}&5k1=UizDeJV zLEngDu{h5HBCF!j{C6CCi3jxmkW^-}kjiO`@`@7UubJV8}_qT@xh zfbrnFeKeJDjA>4_p;P>M*@~zCF^@%Qs%e8z07Y+_0jl68AdD zlWOypagsdFO!q(G=aZV;tobE!Juwn`Xq9{XGObG3=tZkWjb%5kHyp-I--2?82?XZw z+qamE^%V3DpTKRJIUApmUB&I*rNz(Jc3S{ZM*-tw1$iPTk;=+FlaRh&8wT`{+!p2@ zGLsQ5fR#nSF?0z!BiT>hl^zc(b;O?af?71llog)ScWE-ZoBVBuQ!w=(C>GOX$zT|1 zd^apzzLq>bd-K-V@D&}_w{@~o&6@kuvER)Hr=Qmv^c$ep7Xvt5Eb@AZzh4FvbIiiy zFB?Cj-cU_UOdKh{{qRBHA1d=850c_v?Qr+F0IWKdlP{AW<_B6tAST4Li{(tW7Am2$ ziI1t`M$FWBs_N#Lk7SetBfobM!rs>)!5g9~@Q%|}qkNqRQw;c2S}(M)dmGrFEs}kC z89-XsOuW#pjlO{aeI90gX3j?iaS_7<(QPilrJHM#4o{BMpqH0&hq^z0%X`2v_F3}B ztrQ%ADp%$h7iBhp*UJE}UnqLM zpFpJoYzKaR7uA)VoGjo^pudT1U$?<4oP5avC$ z(<$mQq+oUCV(&f!@@7qRv`dS0l(He0#wARC5TG$3e~pRzham`0&5V-X%LG!M8HNr6w zOtj3#IAxA}ADP+Y#`BLIi7*3a3GGqimkU7Jv1_Dg9ob-%0D1>0_-CM!qJxl0*7{Z^6Yp5ABV{Zr9X ztsgvc{T`gsNH8p9=Ak7t0tbzex^{3rR8djU0pt;3Gt}fk$X%dLzzOL#Tn)@66Y@dB zO+6L=7t`CC+ROWCtxD|t2fOy0kG1MwJ~f#n{$y+@0-f9p0M3o_%7!kIQmbs`v(XX! z>IItIevmU@6M*>1C)MMwtZ*jU-gE_Gwi_&0q$bsMgos!ApS=}l3)dcxNX!oJy8h^i zICP(il4PY|mX2t;IGpNwkn@yPX|0l+bmKXh;G^fH>Y{t(+YJ!1wdCHl)y0nPoi)vY zN2|j{T#wfrI~}_mdDv%|%p`vXhnpEOEvPq(Hk@&1EVcByo|`QO1pUFkRW{WHvpETm z&G=;0Trb|$j8pyblkxJ0`6nmvzwNUT@1}aZ9|P(Hv7=Ve z_gr_;Z*Ia&KZOh7Hf-vOHN8k7#t&wRuAy1W)i&g$%Wi$N$`kOI_qZ!@#7SxBJkaE; zKjM$`T1}FG+vY^F&Czk-$m`u&l+RnEO&><`e@m{};*KhdR7aEL_JbKpDfwBuZ3~#$ zePC=cOLH@C+B6U|Fc^m*jWvHQXZ>;WMyRFr2&7J}qUIzcK1On~yWuU^VmxQuA%uqi&pG^xz4)@Ry^m60{bg(z$q*whykr2rDzM{#k(W$qNKw%EFI=Nb%0y%$E?7yAmUwuccL zX8nD(_@ocWjI+S@iNhhCMx^0*1o)(+^V=_;hvbI(796)?7eG<~pUo#7A-uYzP3kIn zey%WD**mpLNYiv+gcn5^=0QvP2;!i+lwfAe#B1iP=i5>+QjB@{aeKI|az1b6SM9R0 zO|${q9!WaH7fGtS!e!I6m}h5I8`@?O(O=w#uIty_(ic6IN9@-S9Uem6$F&R5Vnw2T zb+{^3vU%ShpDE` zxV`{?1*GL>`OJyKoihCosWh{0va8}yh5OO}_n;~p6*1Tt+ylPPeq!Etwvq@&>m4Lb zqDWQ==l`LC2}?!VX=8${Ypbcp-nmoqy>RRX1Vwbl0MttgLY8W10;zcs6i*JgdKhpFlCk`YDb)JKL&5JUhta zo$FkWO@nxEVSD3H%~B2UZecjY>zU>g zmee1#70x&6F04q@;b90OIm(Sy7=e)GT3%712>cskmrFgEAueRbFbTpTwwL(%dDd|z zDYN_SMwP8k*x5st*h{aUOI?V}Y9K$pwe0^7G`mFJ6+Vb^)y0}J;Qa!luc zeMZ=nBWw31UaG%p9X4Tzrw8?KDOhhDCX}rdF{-@ zik3xqqp1s4(%YxHM0o4cH@d8j#j{t?hn?diWh>9NtxmT2dpG?Suw8@unrD!X4IC-5 z(#+%fx93Bm0Ydr7E1@bh8nM;P!&RHj9xp7ZsdtCbnh2OYmj#hXEq#m&m!xIw?Q3nM z9Y|3z)WIIVYY*W4`eeFuElUnjM*qQm?tH)Xwic#mbh_M3HnHHnJS3bYyy~tUFn;261kjUCbwY#!+YNN%Lqt8COj>kIt2 z*%XPD9yN%#S6LXbms?m3%0>5#Cb!hwC9=P-f}Ge>!$enVLq^`Pj`n2(5;b7;+m?8W z0Cp?;Mv0+IBY2;ea}vt$`?O-Mtkf;8s7%|h+EC;CMfxvbo$JE0ys+qt8z|j;0j8i5 z;9!#gl~#eejf;Kj8vGa3723R)|kida6!#@y}C*YxIu?NrZF4bBm_JL3u^qLvK5yp6{(+K7& zpd<_M8~ekmxVBk0T3M9JjZ~*2=X<`$^`U-X+rIurSX&FI=ayg$1ZrAug0(AGbU16{ zI+v2#m83rPRX!Si)+r<7s~XKwnwWo5DR>%bvmd}n($A#{?DLFM_Wv?TFhjC?RR^Z-wB_ylip2K@rNhGskqy`|bIDvO>4)l?xKI0k@8sc$M!2)~dgdfpzd z%c^kwi*0WTD{DeuHqtCL@|0UaMzNO9vUv2~lJf;VVQy*C1sT8G*i@9SsR@JHD>^-C z0P305Kfx(+peLQP$OO49wzseAV)9@*nO#TiuXC^YR+Hgn=Z5O0TNFQKIET$FjTz)s zmSOLg{$ZN@-8R<~#i7>bq*+6)L={6;$gh64d3K)sT}|{|Z=9hZT0{9Tny@l*O*}XB z`UrBoBo3uiEkxr$H2%vr42 zOIl@4_C1i9w>M3~&);=1ny$w3`1pKzjpEkiAj0wf2Mg27dG_XD$FE_u50_*6F?gn^ zVHbmjEj-Uqz(5#>Yv!O6xv%sp8>utVqoCt;F=7*syIh*n>%*r{J2$!xuKo4i0J}~2 zedIw7|Mws>++Q}_HRAWyRjpv8HWZ0mD@bSLCLYgFO=4B8A=;vD9z@w;qip(qHzi@Y zHgH5m%JRn%ku-9$dhw&C2&*5H%i-$>J>u5pqeiduWMQ5uCbHl1bPu`pS-^tUQs_Tl z*!mm4Y)Mb8Y3Nz)NjwkaZsD(R24pOWM3oR@$<1)w*J1U9Q_!}V7SaWI8rEUkBT>8| zrTD#R(;=p{0lgEIc+mVdxXVr)D+v(!>7o^ad&R2UceK9s&J%uL`4~ez_sk4v6~JHm zPub~WAxaN6vG!p^FR{9w|82yRL)=sK%EIEU-_r<~-70GIJn@G+gfgV(PRv1Opir)f z4hj)H=i~3FS2L^CIS4171e5J$ENFB{uE|*^=z=!0g71XX$)J}OrdQ_lDUdLlu|Af{ zV>PB;AvaAd4D2sjhlY5-Y1Ius5p+ETW;5355=D#Gz3Zq{$L zW9OvWSbsV)F=xs$osuC1dMfj+l=RO;-TZ*vy*+)FTdk<$$O(+3oZ(*Ldv1Xyaq~#S z>NU-xU;;b*^O|O*F^ih^erod44LXdbR%|*h$Amt$l~f*Kc9;piZ*ATyi%&AzAA~Kh zSHmwRu+XmJ#v{#In~mlL{6CTv1xPq&8k&4C+r=jr38a!O4Nco73)S?1m`65VQtDGS z-~dIyY^T>-2=rPBRFhl<&}lMOzIYE=;T$sk3nLQI&lRuIy{U~^<@>A<%M|ebrrn!W>Z^Wy#&TZa4BBu)CBO$^KLV*9@ejCr&RJKJovKI(?k zWg0O%XiZdr?W9Ei>%H)VgQN=hG#K$05yrOlgP&kxsy(=XpK z9Kb1I)+I0SMkmRVUPAO66$8Lh3Qmg_!;DnP43uivby3`T1Kf%;eo6V=G6pSfv=`m~ z#GPbW_&*qg1zWyep0VK>MsW+bP)&j0fcQ*I?>(QBO$J))Lhn9BH-5JgB)t1Iu6nz# z->VyY^F_@NaMm#<7e%`b z4DGc^SZSl**4Kv{{8UH zks4MzAzrO4z6Y${9ti)X|4n^}UnrQ>!EFa(ZrN5SA_1!(|G7wXitUgD#A}rVDtm}q zgh}K)2QP2RAFJ!C?+kMvn|~d%!P*ZibI5=8v+h5lNuJU$kv8l6^X!h}`hCU6?O_4B7p#0zJVL$JmYS-i_hA0Ix##ll3I0t3lfjXNYR(vmkkzGFWS2Q zh&}yquSpQ_pb@SPUrp~dSFJ>B9R8C|mG?<_a6@P3N`PmA9p&gj>AYSKb}pA;$l zptxl=@<(Tz>mdDf^rP` zK{!|MnA*4$Ms0F0S#T@-q93cGyoG)b@Et{a#P{d>(v_!P3gBh#!>ZJOF6OSthU>1D zWWwl{{g)KWE3DKHSayUDzel4YQa@2vLCehF5C6sWz8&GopUGY?3p9#6WYz7^Z z4@s|9-b2cWw+{}XFQYUR_vno`Hbay0Pf4O)cB2hwW5uSkRkfe1%SFZ?$U&o5Q7uk8 zK}aW~|JGkJ@7WguS*L*PAVuPiUkW@NQqP{hCkAR-S<5X$>NOwYD^aSI1!-=A;GC2D zDUPqHbK=~;^-X>tC5`~$a;zLdQ2U%>f$Ddpm-pJ|w|^$YD40rx`{Jg+_Vbn@69}Ec zaa<*EqXiR@hsK|p2!Oyk&`EN(x4nP(RPmhtwId&+7g2w(>KJVjURRB=#8pU0f(iIB z&v7asn7UNAdUA4s4z7fvH+;}@bE3Rsbw^{EJ@$AB)%*}wHb=)|xSWtk6sf$}WZEuY ziB622gDr$dLK4H?o!UREw}=Yl-$NoyN`TVW2_oxtbXQUNbnbHH78_$n5V(9QJ&C2} zbu#$r;QDJGqls`p$Jg0UMd^3mYb8pYZ;vIdK*dsSC1g^LHQ-rdj7Gku7U0Ichf$v! z?==P66gK5p&1wz{2}OcwUcE_`nPEfd@;wF=wy7IF5_rdEc)PZ|F=63ZAG*uA1^l2r z@@%4hHJPsIKp}mMsSkaK@cZ(SI~H$w$}@VMf~RP@GaMR{u92hkU=0xXj5~lZR;$!b zm=n@RU9(lLSZ-)H=jHa1Cf*Eev&NsOO#xeDvxGR9lQ4nD4bMP;-qmA`hSgWWQ2U1=7eY zW+eJ)3~#Gaa~Sczv@+E@5dPJp9mC*;=Qx=VV41`wDXkco_vE964mv{acH=WBDZB|2 zivb0I85=&`B1z4((AKaIMRyd;PX}iDezX`d-{!;Mm9e|yVzUP=V~0mQ6}wT6F8aRj zgGG22GyGlO^*DJ(4j6mDn=Ro3D_;K2sKPzO+tYSpW=uJqlkbP5s@$9T{F@^xb48k6 zk_^nSh(8GMyA)O{msH)O;4N-w#vSO!Ow~*ol@4WVh~mW8H7oX8IPM_FbHQVg zI+Lm66hW3d4Dc{`8d#%TV&R4x`un$R&NtO=g2)UdXaOKfrkCa_Q~wg)izm?7bH*X> zqC+MF!^ifhZC4gVF`5a6$`2KqCxHk*ciBZ+T7a_}5`w}(VjCmc`iDpV&W%Akq08eH zL=?I6kcuNusYF55?+fSMXRr?(KPBX#wNKB46`!2c;A}M1Nbq<6wp*k*ytE^sg~04j z1iN=UOqF?qi}KH!8|8lrkw%QEVrazoJmQWY=&L3Z?lXAwNUfKMw8*3Y7#(r*5O-Z` zH*-=KXNfR-;^Is;82?aT#|dD-3n@W(-K-kTQ{tSCx{qn2QqbJ$Iu^}43|(NEkwqC) zDGTPiaLW8^P}A6u5wykv3Y_q?$1;X1YmS!d#Vb7dCtV$#%O+NHkgwGejQZUlZ!kfP zcf%^9_Qllmhq=7xvlXf$#je`4#jPNE=-lCuzbm5qcm?d(`7_K~N~WY+z04n>sCY0- zdav}i7d@w=Q%CKwzsA|iRmS9At;kGB0ME9l>U9vIZP~R(@;gde>rvbUDMSi8=hy5J za@H^v1{8&Hg>PH6_R&6MCdloBKaleU>mUGh`w{doEEcrZjqHU_PvIL80blBG_ZE0l zr{EfIUOn=EcM9yqI5*WN{fba-C-fhLT%h%#paK^6h-WV;60)95*Z{-;q@vHE25npg z>ZZV}w=U?97JakSK?7mF7Q*YM3z8EHwc?4+uzr#^IZ{#(p6%}(^g?2DLon3GX%4s! zXPi!BSiswzdF(3(IOVMtKz&R;iy9aY2dTiiCK+zhy~7~v zqhBv~rgbG&Rk(<)U;Mxp=zBR0&TKT;aR&(u6C2djR@%H-^m>FrSW%EmYLhFr2b>9K zsPm*L&)@4HC8QAGZ|h@$a%-T^5Dp9sB()xZLI$c<;c~e5Qt+L)wfBX_T{NgNu7) ztJv`AHI;uB&TxVX^|#$iX|(AuabU@J$#8EjYmGIr*y{PgBPuI(%Jt%%P7Iy*n3~q! z!^(D)1TqBouyr{G^!2rmp(SHTO~JI%XEhi#5{n3qc_s;;TI8W^#*&mpI z89Yq4toypL9jH$_v2iH=nFnfDM+{rYwTb9kPuZdTBx_WCGKez@$XB^AC4D4Tw?Cf| zRg+`bI}Hd~e1SI@a2-AW0PNS6Am3w5PI+99s9l)Zjy@U7jdr=klbWo2YwqK7y?jx| zJ$8+7w0R~mImWK1o8jIH@6Rpd*bs2TKesnUkg)mhE=lhoDVmVG-bH4dGLt}+yQo+0 zx=`P`XRgTWy`I!Y0N$Doxqpo6Iq`U?^@6Cz$_0W&${s;d43U_OK78U-)xXPRc@%~K zDiSC0+?_2l?&t>Vf`uwEc0coo>-uO{XS#fM8wBI9$u;T{RqqAun*;E+tfudiM7j(G zpA0#Wy$G+qvT&)bl0yiyg{HZiAb@wdtK}-AE6!6SLS`-lHl?Y#e7v361!>)db~f_0 zn(hlnwC;;WnC&`~kXD2mzLH1KZX5(h`2=#Hj#4(|9U8e^DaTpgR6AXo0}1nu?if)K z#Q!Ew%;z$HHc3Y15QV7{tW>E~|EI}|_c;SPqASFwD{rk`6+_s+N!O+iq@MytbHpYN zY1;LYURs%7Upgb$PXn;{r{l*j))io@T%gw?UpD@A^$5-PrEpSaq?;=(0H+p09;FZ? z-+U1fZ@J6!IRiH0dBY{(YZFlS{=z@7^hT|#B{0vwyU#FiL<@{SVf#N@9!5zb56l48 z)uLSsaII@cj-7wr)mg>wzZ0Doiw}N?poo7xDI>BNi~F%TOwY}M#HC-^ghtbF$rY3D z+0SIzg;jMa^WzT81ZLjIA>yM6;!DVMYIcb2*@I+t7)y1parSwBT8VxM!M?x`$EPkf zUJka))(TbN(Ac1V#%u>*>x3FMKlo;#gLw4$F4Et*WfrdGlFp;>U!hDoUmZzm=J!sr zjt2N9HTr8OQTkS^Dm~GboTc%`_pMYy;FnZUGuASsWS;&}WBoY$^XbARr8CjA>u^a$ z$oWv<`UXv7fw&%(?)Mp=A6|6L&!U%h^~;oP*uZmlVqKN)umiEUIeJUnm_Au(prX(9S-0qNz7ztfr3~i!&Ua!L5)55s|#prgMppeKh2f&(EF6grz&dFNNG` zUk>;uvjAJ_{N7b=*bARbE9JA7U$&Z886SOF0M zNmCrx`wo^m zi&S`b*#Xl@7s91n@!Nd1mYRUblnYp4G1yi4x%89YX#&cy%b2RmZ6o zb?Ndu6jSr8S58viEdtwTYP|yuyaLIspp4F ztU}z-OssR(RM*9|m&}tkLtsS9rAw_0F!Tn>wD+;xaGCZmDg&;5bi+qe?w#ySckdC) zz%9T=NIqEP3gnP2O$WLsS=kS@hfA!DvF8!sZiK!w&L89KFHS*)vX@>Cw4;Un;Ypm!6F&-qdR ztia&Yaf;l~yWZ7@ooKiF4I{xr@eON%H<~z#gSn2)oWRaj$WnE3;wkgh0rX;X^m<8v zoVv{ZnMoMG4V^cfMt8#Rdc5RVpP*ATm4z0~okgY@trQ;tVb` z$zJ8LdqtW8EU-FMpQbRNbzN)!5B=&f=|Ts$f*JIv>}3-Bp|Rui=hrCzpYQ!Rz|>Dk z=QAGiFbDqaBL(+}dg5J`)MZh&$&&CSDr`8%rN+nEwK3j!mX9jjH<=2XGcax2CVl%esDvXhym6y zBd-_;qo>d54#z^0fjcc@C~hRZrM&|;ABX(OeTEs?5``~``UY8S%qrgqfoOivsS{0P zS*uAYRQV%u#d5klTVUTKjf00LS%%F|oKi2hFmeh`saL)vT$uEXkr+CN54o#5*=Gx1 zk(_#$3;o`Dt(BDas_udkDhM`!ny3OB3Bga;%;aWv2;2%>M2{I-9RxAVV+6m7rO;>g zU0C9bQyoiPUcBJ_i0+UVYU}Jp_hX$Vv$o0`E+ul-?o=gtmqtdHt)gQk>_aW*a%lXQ zZ(h3}JYODVV?n_W}&WeKxJor&h;FM#}uN|tMo(opat+VoPcsUaD zVZ#kM%|j_7u{u11Z`xW#BaF6B``f0&WHZ%->QmvAk-AnpEG#VLEaD`Gz=6^}Y|_Zc zN>1m}&n4~a9&^5G=^g@Sycpj9F~$7rM&Gv%LrKS${L&)COJVir-x#|>#U)?JR~+J$ zwQ)0Zw@-P&Yrcq-FR(2zdMX$8HP3%7|KP*6Z-fsn$z=T#$)v0 zyC0ca`ykz>FvJ=cw!7IOt&%E>$OUT@yr7ZCYrUQFedRhLw3?|^m-cqyrrK+Ka`J1| z;K77>z*+KhMDxAq8IT(UWLq8V(XzhjC+X8fe?4*hQjAyXFMlTyyz@kKBfj_ChSY?_W zNHeK#W6u{Kx)yPKwz!L!RCJMUQ{E9KyJzI-gMC-+LDLej14wbw*%9}hPyxo#C6S3J*?k})6hRSN7n`Vs(ROK} zMc+yQJi(V7)oq_@GSj32{Hb+k?eWy(BL7UTJzwSTzdp}#hTgp;9ZN#m>Xr?!cXZz39p%<@{*sqwpK=r2z}3Z2R+Vjl0W&;89eZvu+Sg);DP z?TKwT5MIZKUuB=?^G>bF4Jeemovt;z`A5(}$f28jk`~>%fvcoj$=kjBMmLVjLKt{Z zkw2#(Ut%?cGlj1uzgPpFLdmar{q<<*-jS*3>Q?viuljg4dzL`3p5ubjei1i0gCS`M z$b_YSm`f2HxE`O-o6AysxIJ#WPNcjV)2kq&9SOVkiI!3Zu$&}PYxo(uaDEQ|d!Tbw zq;y4WgcofG%Y}qdf}OABlb)MB_?-l0T4=+x%syWsjyKP%p2p}e*uQo_SYZ4PQ4`_c z@O1W(+Akq|&t*N9Rj=k^RJDX4ZHgnLO8_t*X&G z{7r?7wkv##Hw^yi9cMVwhgJLDWZ+5nE*Ah70rx;h?if688K49ExjW#TzAF zW;y9}3-`yDCy%X-aIZeyu8NR(BD($t61D+M!7V3kx97(JjC-_y5+8bKO~zvu{@A!R z%n>z3>2^}o=^P0m48z{EMu6vA31)bTHTG(gjPCd&ocp_vHPxzS9Lpm@_7PJ9VaAz5 zEBt;s03-UP{*gE0L)!6CL^0>-Ulh=Hp%Xmd9P3>A@$$6VVdyU6g)w^8)NK&kJW zedH#337AYqTK)zP2wb2H4OL|%)a$#%q26nHe8{Al!_O9uUGC7Q3_bpyWyoNwLWC35 ztY+rP%GyyH2-#Z`f7E=?Dz)(W`J>1m)Nx-o+=4dkH@q#Lw_FAezC=usSH#ESuvUm+ zCa{ct5zxc^&Ww2Tm@f6KHIpuTK&q`va5H=jb3m&rHl_7*hp80rJNR_uJuVoiZ{YT_ z^bx;D^Ablm6@5ElEPAs1z(8+UALdH$Cat@CVNrHzj$GwP&x{2dL+pMCRD|j4k()Tr z*)|HkLM$Vr3JF{6@wckuqO5yhnjJq#(zNk6`4T6P8pQ>>k-zy#f}blv;uCt>zQV7l z{BBcs#Z}8?a!u~7JN{OU9-?x4Dhd(vR_L>8Bn2IO_%qLG+U#8KwVHW6hiH@g&<{1@9nOxUX~ON!;wI>|2)> z{jXJ?e!Qs$;lbn!xTnFnKUmzA=3q7-dB9=OP}bQtX6tXx1^R=5e|5dDRs_(S)O0Vw zZprdD)qq0JQCUQ6aut=ms{jg9X-hC@$>~gP3!quW%6>Rpb=jivs}i~hddlowon@fB z^Fj}%Cs%^jzHrS%Z7kl8KafjaLU+|$xI2gkC0m~TeJsn~lh^~22yD0?2)PL}QF$*V zWp-Qr`P9exD{PdgJ%;@`o7YIfN;PtQvksGVHE>@m{*R}8$Lky#Irdcn{Y0M4@K6d^ z$mz^8ifMBMdA*`Kn>sgikZ0_7=L@GQkf9IT`gsFqUw0|3i|k8pFvK7eye}8CX@b2n zddQ(ea=36uk~AJ9^F2Z zc~904*O~%|nnw4?YDAK2$mg5FSfK#i24$(jn9%oNGa!3jUOf|b6UXA==z5q2 zBw}{>r(M=IHs)!#@(RZH2XzkNT3Y*65j_Se?m)bM!6?EFzAIu57?=Kzpf#9og zFrA1e}{>8g5xwbEZE^dzWrC=Lilkf z{=Db9uw0cT*bEsw9z=;$1u@A*tJUmbp0L{P+iOr;n4Dxa<$hgm1brnQQA|6KN|4-! zzf*ay<<4P#D5x1QgR{n*v*GrL`_U%A_k;smAcMLOCwN>@I8z>%X&&Y)GT^3`{nulI zsr1sCK4c5%T8d?$ui;F)cVdD29tAl4%it;UC}(>Jw7mnK#|Z<B2zvRKi1Mu zn^Q!4xk8Qe73qIsue>6*QsHH~H09`p$!k*eBD#LCk`n%|B)q>XNk)1!w<0D6*&;pW zm0RJuW3H4P8O8!`e4?-n=Q=iGpHmoy$fqQH7?FY&Yxq?`do{*Syt4EeExpC_m|{br z=F_%*pvGJD<@sY?-1}nNY*d1U&;5G5GLr4?Fxq5hNqA|ja5vm9Qp(t%2@d-c5a2$^ zM@*iFJ6Y01?4|dpVkvsUs-+P_j0D{Gn5EnqK%c_&IZncO)POF_ev(at)IBy{0y@}k zyOQXsy;|QA57^)3$nBkT$)c#bH;H4irf1Yreo9Ve@c$CZb`pZ^PcN;ILEXLR;OicD zk?nu~*s$PO77BZ;ERRe+#171olO_yc2^HgLz3JIwf9rIJRQWN;p_G8*`=i^9T%Q2es{NDW93$+LVjEmi4^Ok zC4c^uU6SBQ5NhwwvBs%Rcp9nIcaU|@CFyhRkAr`Xa~~}*pnvjJLC^X4_*lcn>$kuv za-VBhwQ)%~Rz5=jf&Cz5$??-EgCqY#G6_z!{bV|VgLjW9crxl`6x@GJ&{?yUDLw?3 zBg{L*M;aF**_T6ayQ@O!wYv>wVCONBl-R8@@Y8$SPjqf+#8brjVK-!S^Y>r3-W>i9 zoYzp4Yd}6Y1ZpW@;vu%J#L_d^1pZ4Jk^LuD9vQ6PX!lrYiZYj^d_=38sZ}`X^5O`W zZxe9c!}R8XFT0D&Mg8R=C48oJhu>s>Ee@_c5qjUAcfT#7!VXp9?)mVZvn-jhTP?xk>S%7_*{6)%^1 zr#=vie1!>84x&Ax(U?BP(IiCRj$zX3htGp6B#P+btR`mAB~zwMGv6&c>P%Xj@Aa!C zl=v~+TsxD>`j7&d?l1-eLN?ZU<{wkNY-hK;ME&jc2od2q#}2*EsjQB>V3$VgZ2FJe zb^U7r7l9&=Wy3|!cj|F~&bxh)>vR0FC$NB*FZ7#TRCJ+i@DUQYd^`h}kAq;#Zv60b z<|RF9wu6zO`5YbD6f1BF5k|6o0T!vffWEgyj4XDxN=|>2o3@ffh(`?Z;F#Sql5(sN zOq*D``h2`iKIPxINq>Gl+I;D_*}dc=|-mmRg#kn|3YPGuy}PJgl0LNE0}7U z7RM;mZkE{M{xyzVj`+&BV_i8&38Q^a){+Pv`w)zS-I1M^CFWV8}K|1k7c_AA#^c`Z|kVv$KYe`w5w+(>i{t z<2(Ds*4({W|3nE6h$%0UwdZiPaCzrR!LPkrM%Uac`60{Aa8W-s_5I2uMd44MHM5l} zUW(+>;r>CW7SN1YGZS-qs^{koI+@M^nd-E~t`%K}EAxd+68YFb@m3jbAWh2FPEFl} z{VB!7lL<2xO%61HI^Op3d%wbgsI8NR6@Ivl4KxfpGrZ#347$0Fb#Qog*24+WKYx1i zj!9F=dqv-dk`2^o>4g}K(#QK%syKIaPz513ljAOvOQSy8Xdk!??npi~Ngj0~O=Nz~ zPfN7DP42GG3{jN%Wbc=*9iAw>ggpsc=z9T@$u|mF`RKP*Mu<*xOl}?Ynq}Dh!^J9j`D{n2*x*Xz>076LbQjJe;qX#&4hMBI z=)*5cUVYiZA5l3xEIJRn)6z)aFmmcR2^Uck{Xh`}10WBN%>Y0i_-k$Jj8@3;+xsq+ zntml?zWMki3eJwhb!JGb?<-e!&=_oo4~e!Qdxn1{mHBJxtt~lueGh0nWbJ={5+i4^ zZnifubShsYN4Z+)$AEz&0xSnEL=1ezW#hnS#X!H4FsMv`lw8QvDgH1Z z4ICRG;Mgc3Xwve8K3%#eqB)2|NxKMTt7ua2sjS@{yS6=qmmC~#Clu|Mft3T)V0OV) zo{Gu2g_Zht_;7e{DZB4-hG5f~=ETQv>@s^i$;IphWdU4$Wjq4RdFLMO-PSs!A)ZB@pTVs~HjP=QU2XC8lUB)u5I=3lS+5>e`yc!j z0&zSu=!}XpjgmgD%Y!C;1Ak0y=XO?|9>8c=|G@7!LCf9uk-;A%}SnBCxO2hcmXED7Al2c(E%_uBvI{>9_j!- z^w*Cwj{godro*S~X@7B;p+|{65og4+m7?LzT40$6d7EPELPDBAtrf=}L^i>r@?=+x zSgGa0Z^ycicrj~gjjU==qeO-{oox1<>cV{zKX_jGM`GAp@&PB57px|o?+ZR1iW#f} zFD!lLo#Z-QlwN8#0JW&w*a9QP)VfrD1ApP>c+sHH3~386>sdYqe&l`?|K)_1WEvEj zJR>*h~qn8%u92^v6@wu1pRu)p&Vf8l${>TMF=8r$Q6>UtXP zi1aBYt>)U=m%AqGvkyv?;z*w*f8XxjE(9-&wb=7v5%AE^@Ca2VtjQ8wpvGZeMuRnK z)pG136>^Zna-;>JTee?~Ws+LrVh41~f#yl6>!@fRb-W1Na^Ymst$2#a?B{m0@?G#N z|5m)PTc$9xTEGdbC*)&xiE6o>cykOKuAvv$pF-;OQphqge(jM zUPfG9t zbtJ|*EaK3&v3Y)|94%==5Ng-Se8o4vKv?|ef~F8j$JhSt7DlbG0f(WT{{FfTtFK53 za#gTXEM^&xfo5nEL<4&{Fy)9eo0rhzhoUQ{!?%~J-RH&l+aAZ zj~Fk>!C-W|IKF>wQ9eH{ed0QYD7D|`LM5tyXfa_D+3sVOaPhxB+xDG0i_W9dgs-vP z?YGV?8{8M-hjVMRUw2EMyjbOPdDwk_v?+>PS+2wSuLJyU+{x+kxhSuniJ0g1KDX^c z2R)F{s$oit_i{6&Nmh);1jeMb>$@waA^WQAs1OH0oo0A2#1_BRsMv2GZ`h?sXUnXR z5!C;o|3^P2vJ3_?ur`PB|r!V!qd_bd1 zE~^h*r3r6-yFH6i>@6e>g#sAw!ztuBg^o#ufH|_D9(v^Ys?*4`8y)#6OX^v|R_@_8 zfvZ^_iYP--%Co%eO9QJD{tN_eG4I^{R9z!9OjZ~%D`)$Y@DV`5ZNMv1p&Bjkv(jzb z1Q8g|EA)=mIa$J5B^%mFoTBWLR5*C5YTp6D2MgZN==+qYL9X2J+&^_Zl``~wA>ex}rVsepj#=&Z3qa=fN?)P}S-ZlTpWzPaPfq5JCj5YbJu@%k<+#Jg4o_q}=IT zEprMR-RyY^61KLv^`&l`XNT`}d%1w6@sSnkxNoR1Q;2mfb;Q#Us`%Vh!%staIBbh7 zZ9g|F|7>p`?ovjmVcoP{CrRQFFI@h*ySbu2+}dff)0CTom=m-rr89L(7;z)nyth;H zKw4|66WfInS{`bN#_|I^X11>BQ{uT3{<=O}^d2$MWTNpO99Fiya|Vf*KHtv-hBySW zBhNJ?5@?+r1~}zVCvau$OscUeA6cJhR2C%_&?xufM`ik+dcg3ueGe1GT5GmU?>b3> zO34}W#dPYA-dp$E;ZpyS&WM@$u~`i=3F`5RvYV|^nLm;c;ub9AU5KP&L!anJ z7X-*62DU_wib1(qM|bBNh-G5yS?(PobEHKi$%4YHAa3v+jJ&#Z^9 zY_G-fahNF3SZwd}+8#vwVkslc`y8U0j%$P7`<*2~C$d36b@ozd?JyiyDaTDDyN92r z$P!Z(uQ+cv_L=fHs9^a)5s%|xY9zrVVj@K-*k3PJ-n&NVJ|3PEL$v$FFnyMHYTFfm zmwWS_fT1Mkx?3b@ti%yJXht_k1~hZ8Pq)oTXGpVJ^UkytmV$kxmV$Vs;m%bApuD~@ zj|WgS3*7f1PdF@88exvUPg% zT5v4vW@Y+bs-@AkMqAsfc9P?8C@Lqb(K7NPbbpB@l1Ac0`c-UlBu=ER#ate z>+QjBS&8l-%&L1qRYG|ie?Fn*_baoAohFrye5*DADp73_O15{xc&j_OAH@PpqGd)d* z#MeKZE*?G+7OsE$G~i0-R&J73nBsEnMspv>_I_$c>gMEr>8AbqN&d|Dy1ZlEhDe|Y zQk69Tg*HGXsio^pGUf-J^(FlcN3QEMwu#C4fD4CxrmkQ4-&Wo~L&v~K9SFkBRyOd| zTh!f8uYXmCYr?SMr_Fk_#$XpxmbK66HD?EQ6QHDQiSA2}peFD8sZj>m?`|i?7>F4} z-M-H9lv-<3e5q9zljG+&=gg!i%Co|9Sa83naWgMDu5y2-BTV=T;2LchA5(NE_a#du1zq2wC9J;RxfD2a0`2%eN0T|Fii`w z(qpLgxD8?R5wDj_iO~>>2N4a}z*=@b1sv;up;=A9Bg#x%#d0gt0ZDiQPAoQ;i<)3` zMtV~L@;+awr`>9)tmp19(-kxn&G(Ho=Si=+Fy_T20953g0O+N6?9 z?!NuFEK01F@e@>PYlBmq3Il2HIzA1o?-y~p8sNg~1!uA6XCL4KUAACl{HKsuLA5Be zAUMf^ZIQdkgxKMjRww^u_Zq+tvxwzY5(#jx`OWiFeGu^ev@Y?R*rtFlMOhk$e#(dVzR2o_(ioEBJ;9n1kLzUs8)8o~tkDI>kPtBN9LBa!zX7 zZy@?&^i;7dla4lD2kecK0&(8c_PD;EhVb7tP!RcF{$c&v_qk@ty=MsD@OlOhU+R_;`y+hNW&7+768sy zMT_~KLJH>6DOTFP)&3Elblb{<(r+8%6=#aMwD}G?bQkAZ!FUO>3ESJwDfpcNZm+8- z!+}l?bSZGNolobuJsqSTdrFw#nTaxMZC2OS86iow=_GiLvE-ygfmdVX6AMAZk5o24 z$8!g0EJHiX-Qn7GH|3p*_u*-{TK9_rl=9vJQ_vP>+p4U8Tr8?P(fmN*kO5wA#PqfH z0@tT(Ob`Zd6kVtq*$7ew?Bx(vg}$9Nts=wm;s=c!o|2Lhy!+F3SN!bT^mg2A-?RDL z1E^bFC@xIP!~a?M_Yt{+3s}!o;Nvebn?W@nbdd-XtDo4oM~>XSkr}-k^k=zZNn^Py z)pbw(HaEqqZ~9QmfBB}Oi}PW`P51MwWVxZvNCTr6n48Eg?f40N|7lbcRvfLYj;PW| z5lXpA1$HKc&s)JVs%ws&SlrH6UHwz-uRkH3Q*q7Lto8xb{jGmWjO_Gv=B8HQK;-qO zLCekN!5_m<#{#GvPT>HJjYM+T29i6v2EN2X!0Xp?x!^RQ;0d@&;cZqNP6$Vc7~P3? zEr7W{J&%|k5J{M?Y^l@oG3~Q-8YdWu%vSK#!1Q-2OgY_K=IJf40S{7G`w934?s}FZ5FeEsKI+0v90KRJ!#jh4266~NnG^aEA^l^aZ@qFV=}M#sLm-nzHItAn+7luWqs30rM$v1N5zha`h6p`-7*{4rEO7~ z71BkJH;z+)vZ=gI+{n!&OATXejbrXX4-6blHe+jqb=A=;2Mf)yc4TydkVSvEN`W7{ ztTz#2rG4iD&Zf=}Yczfj0D*bq=;-KEdek^j=u=tS%n!p}8Qy~zPxv;gVRCW7bRgi5 z)t?krplBF>ze+hv70HMXz}kByjSVo0*Rssuf)?w90-h0jEuMqpxA(9h2M2sZ!+Hzx7T-xonmQ2$p7+2(X69tw!fqVk zU9(j_fN|)HJUw<$*HvJ4-e6!>m4QD zKYZ7vZ#ImKzP*{zotkgmi^fzh@J=(2Wgfv5Q2&PJc>y@!jfVp;9;yaQL!<#>==C?2 zfhQTMJdM$^zE%$NBiIqmaGqy56kdxa@nLxbbpVKJTUOHgtoAOSlp_-p3{m_FU#(Sr zpc;0e3T})gBFA`j2BO7wR=-jbsaL#2J1pu3MU3xR(g|H;zN(l?(I45DCIWatvcJ6h zXkl8WelN1pswIftOkBrtn$3N}=>{iw0b`cD04|a85XJm({Vny@aoKSAn;MG}ijq7e z;}jx`Oqz0qzR6y`5EHDcZ4q``oA_xT#c?W{Z`8_&EVAkAJ%(yIimP>q>rIKzz)TB- z*?e~@{JAZZ3=%ZrhrFKtuJ*)U=Red25Yd@o9@})&2Qv;?i3oM=VK?pnEh7QZaUky~ z)Cmk_)hWj6tm)B|SK2o`lDB#hK)TCbyWKXj^!2NGwtbghv`BlneGt1{*6VZ;ir7)& zkPW-H#Y8`@*ueW%D=OAxMKDz z-M!`pDSwlT2LUvpzZTmB?PE6O0|}`-?(TH6%mhG$mr37vw6ER`c-T;c2!A^B(Da#Kp?UeK^q9jPdx!Av}^I zx^L%Arpv$%2E+D|U2h%#cH^Z1UE1|G(0jmnR{RoXA@TB`yyO%5QK*s!LqZc8w?U^OIR85!jvQrqjpx17 zz@V-M{<2RPkjUJ{c(3o2PN|kigm`tB#-t^@@}spJ%ro{7i50IYTl;KrCloN*}M0W(jbb4GnpOnal z5m-XA;5fSreesf(uo3N6g}O&5EXe7wN`)M0%D1`#Aec`Jyo&35x623UJn>gxj2qS*tIOt!L5dNR)MshVMq8Np(6h`K?kp_9Hvq&cp5vmuK zOd8fdGezU@(ut&zT6z0;+m7p37*X-VdOH&rTqJ8pcsvgR_fF@B%~F}Gq3a)lEc*pk z>B&24!hwj+BJR)0(vrx=Q}gd$<&o5!bB}&o#Zz&1t_0yiDI4Ym*D*8iE(u_CeSX>% z)1F^pUR0-iy~qsisms}E zBsrWC;K(rwNcn2z@LCXqvAGxVdfu<-+QH#Y@qBYUbad( z(USL#VlYfnNH{0kU5h51j~NPmldr=~AOVd8xfO2eI}=G=aT`)@i4mtOqY^^pp%20h zJHi}BP{`5ssWlbz9_u${y-Nh;fQ?# z_|!1M#=S&Sq7&m&0*u1zc%`z0NFo7@R2-|N3_1;t3$t7m6QXb|h?M1Dn(*uLi1-I> z2(RKD-sHMN)wnceYfdB0o8QCyFHb1L+I@}LZ>#u*`0elS0D96GjEK;hDGQM-?HC=4 z#p5O4Q4Z0ogES%&X~V7|RND*;yQ@l`jFDN3Kn_^T+Qk*1*`4tO@f3-bUv~~o%YkaM z{cnb_jzPfu*s{+d@;TpFAWtWTkw+*x;gdK{7j0#GZtv}6tW#m z-RnaC=4jO7l7fRA5INv%rTx#_^(ZgChFqY4wk&e|C!Tl=eml7}*+~?zSg^e<12r~I z$KtM5%0#`yZk%^sbDs7tU?olYjSjsLi}y>(B#xPBZvb~TY~(PI7+;~O3v~ciy`W-@ z_-P16m(D^ov3U7)o*_-jI*4oV773dx%!%q9R;TqKx1c=sJeX#ZWe~Ja0A5E#cu|=D zSX(CoL-12t0#qENOXN3UAE{>h9og80Y*h<)7yObcO%{aWmm1edKYlB8i$X8u%M-1l zOQ(XXAB~1j|H^YxZ&)!fmWU``CMC`VAc1VLxzST=rkLDLXQkuk?0`TRfX!cY$3MNV z4`oAV6tI(3d#k@9Fj zKfmjKq7<3F8Y@2vMwkBZbt$E$UVrs(ZMm|D1E_DsOZ}u#p|Gtdnj#8y_%K8I;U&iX)JvORw};WItN=sk9RKi- z9TNLY7bRz!z+>R0N<|{1zMBg+5G8rE1v;tWl%g*+*3$fV{LAInjkmXJE6*<7FRy@A z2(RwF$;@q)C6h4nUf6xB*`qqq&j8yC2BP@#|LkPi9r>ulSAhw_rO))l!g!EOQIi$L z=WK)cZb4?|A5-PJmEeWg_U}x}d6jB$Jv>>w(~X+`su`Zkq2M)~YP5>k+GO2td&2~} za6Xs*;pWGF$1%mi_~tCx66?HQY-JT@=u3ja89#k?)AKEhI-rIsQDGtOCFLDyg3P!D z>K$-!9h@;y-&yMGa$v@%0bLUV7z|$<`LX6~)PBp-r)u+_el)r->PLOI_hPB)%xTVd zq=m+C35$1uDk3s+vMfeX`=;uuOyb0+Vb>k+15FV;TIwDkk#!lBLs6LUy~6?YPqV_{ z8+~#zEHL&@p}2HpZ&=(E-E-w_kt?!7D<@JuaEWotVw(<7_61VYFErdcAo$FD!j*oe z^{_Z9gXi9V6!VtK-mu9=0f+3Z?6E~=gV(SaqgfOh4VSQX*$`qzH zL9dub$HTAI&!FU;tD$(*d0cj#Gc4ao6v(mIeA(NHm0d{3{Hc^qS z!CF)`;O6&R_kKcp4~1XNt^^>}YHN~S1{eH(O@;BmFW{QX9yn(R_vi@!`|%(JTNhUR z9L>Oyl6xoNn7Afx_Tiv-v_v2Quh_KU{DESCjzfAbAE0i(9d_O=4Z!{9xOEq|-I3rgn1VfU|(m*w0#I43qkrw00-s~7e1P|rSS3UKhd z;r5JOc(-vCn-ttAr+vddHnitOOVq)1jL4n8 zuLJ(QfMeLj&|8rghLS~!nb3&Gdqi=^-zbS#GEp?SnO`qYDWG+W!oQaOKe-9V=wl}p zj|ZbdP3VxB?Aw!prlpqc(T-{hlZ84rX8a^Ek9@N4FXTj;)oI#g2{uV7mxjcFl9@R}EUF&OvPuuXH0XEGW$SxbqZWplHBJ;xQ$cSmC0is_C)|}o;d`Qz zI%T>uQ@!=rJk<8um`fyrRsP=NZDM1>+BEvU1C1C+$@Z#^(wTloRrD<3K79u43^?GG z0U3q;aNL?)*sRTBGA{xV6;<_nT1*s@WRh`!HpzBWiMM$xO0;f)(-1LHI62a82tpN$ zVqRfEyoLl?hTTU6puV`>LFUD+uPNdOLoY=cz(92Rw&ML}nyeeJkrcuQj z;Xx>el)$`W#E|W7t7lu}JPeN(0$2{DRyMfe`YI~aiykXjha>klBPQTpJoa{kKJ}=J zN?=Lf`2OzumF>HIK|+>5(svmi;sT0;n(E#&sAYhJ5rpea%&h(M=!y742?l_nRHN#t z7a=~Agdlt9!Mj~0vE5B4B6c7+`6CF86&<3(3z+j1>dEOatzG8-Au`MXJPV%te{C7T zqltO{$zJtPJa++fR_-agk=UR@p;n~FUo&l&o`b$sbQ6ymEPH7%kw^fb=uZ!=1lh{N})=vwo8E4J> zVK>}8(|$d`tK+j1fQS+?H>bn>_2N5aDBtbEyAe4KZvfB9LMs5`^t$8_!fd-G;+b9V zvDg%zjvM-TLP{hgB$m;$QLvc8272$YrHBt##6eI6;m*L|;2-`2kIrB;RS5LP8W_cn z?n6Fu&9E{v6M_gMmfO?At6tO_|HMn%M**Px#7)W!tgXR{9ks}nGPps)jk3$-xUv){ zwN%ljM5(23-3SFO`m*OSKmHI`v_*H7gr^@!Ra>lpMszgH2cOAGF@f)R3ZLw8o zX|K~tPrpy!Y)r9RLKx+Tk=t>N(Q%I)@(?@_`@RaduarZ--^lta%5RSs#csuWQU!M% zqy~up{6O7}iV5SnyH_iekN@zJoxL^Mm;IL^W#vfGNVZkyUZ@m7@uBBK9`QFpZY&~_ zH=fziucUKg>PLiRm;>g{1VC(L%l_XoX$$}oKDUTtdU|nSoUM|8 z2rH9|gXJ-~$oeRDT`FSNl|p{l$@tP&^a;hXl3DU%^L(fvcz00Qv7mnCHs4lbj5hcP&#f)5ZQ8A zF!obLYO-uCHPl{rBnjTYWGbK7CtUQ#)IJA!m0=Exr@1LL&s$#1z|bbd9MS_>V>qPD zfV-~MkTNf11&mzY->qq9AT){;U3$5sQ&vbeNw4~z!&$@rsmoo~yT_%2CLd;$3RYI_fE=q+rwW@{RvwLG9Ibn=D)a?|s-S!z6R#b5!Y`Rnl zL~VCz+%^z^zbeQ{VZzqKzh6?jv&Ydu*sZ77+iw|v0x$O%fo7U7nCZR*J!5g`dV z#vekYiWy1akc@D}ysg^_k|%&knWXlxef863xu6$hl2mU&=|t&*ZX(7&Yp;HFZ1N9 zK;$tu5X;k_?idH^MKHwfCkiWMy)p}(0VXGs=36Nh-@D*B$-sfA$@x{`-F1RboW2N$ z!k~6dhCr=Xzf!nY$xWD3x3c?IK`|I(Qk#`;E)D(U&Ljs=Ansn7h;wKV{`|Y|_`VQq z$sC1HQ{oUXx2exo(M=!sYMZA!lX}CLz#@uigI5z%l{9&P%J12DRJ`Cr0) zlLCzi_ZQ&Kd=osXun|<(ttoa01hues*UP7~*pgcTRQdSt9b;aiH!L_uUUcC2QE9!Q z7qq{THMtg&=E|?RoLr<&4HbR^aI_qO0>|(&M(|%5Q&GJyTfTAqUEWh|Syk;mK!Q-9 zT~AxAR*`j;m#zZ|Pq>Pr`@A2O5~k!LVz|&%_2nZx+b8M)L8k|%M z{FDOpa^RzUvk^Mm;o8M)FDqLZ<}(FvB;aawuw}z<$`0)CGJML&*;qe|xr$gFm;6_| zzyBpM-ncPBVs3?$JEuU>BXmgWq=CQ-0CKVrz@;g65 z@!1?iyomaq4V|;+6`BMkvlFfrrV5v>AK%e7oGrFiB7G>PdoYM06MV`=G#EEPo0z`> ze_ro?;t;@ocLb?MNmtkqz%$He#r}%`l$F+QxHTHA%mLgH8gas6l>$DHmde_Ftjj9M z3pWH2{pzpl6r{_TFtqxZZBCfj8JwMXy8{QnUhHk~9~sp7yz|ifgo^+=wDCg+YYYHSxCQV;D6S7COB}kl778aEb$7 zgvG&afY4jgxd#-IIeXKUhJzyMM&;)n@cG%~98pH^LS@LIB~2qmIzjCwM}i~nW%ggc z;}b-FTvrMv$nm3HVigwUbedBT^IbnT-JjkL3`R7|YgXNCl5sy(Gz@JX_&= zH!l?Ghn<4F&UbypV*TP=EM!mb3#yVchI|wp#m6eiB2=wkmmq(zaZ-1*2=!^D8v<-3 z+F9fIH^3b~nPJjFPtw_TFlBvZME6|wG@wt3&^uT;`h;Gb?h_>s2pQ%88LM?tV?aP^ zlMtT6GY{`p$OtA&M-KB5`HzYc;nt}zYk*l9?J~{Lo4*|yPV6Ju&5SUc28~k9dje2y znN$;?OEoeqb5J*lDc`cguw?fGPB8CXC4&fy{F{$+=OkrqaRKS|M)QPe)NV4bk3S<>umlUL`9UOQbmw~{JH=Q1x8d;*W=U{x3$+s4 zCte2T-NR#NwXmPKiFHO_euQ&L%rR+8=1g55kVps2DgOF{Jo_fU{pFGD<=EK)*uZYH0k91Z9*N0z_rW=lF*S5Xl9wa)#AD1D4&} zDk$iuP*9mMkUA*@h9-o!N`kjvNvwlHpK#e7sh~7z^?4Y?2*9UR-%c&N9tj4U7Z)ol z1@{^1vhH&s^4g9GxkJ3WoUNYrU&S{$wj00vX0s> zH$v;cqVjmpo++EpjmG+l{tO$O{6gkkG0)eehK$*n0%>JXop2x>zy(O3{Mn@QqfN?r zQc}US`U`3({74TGAvp|WQY-9}-RkL)=CBw_;o*0`Meo6S{Rke#fQm-??{E5a>~QZ7 zrjyuPG?sw4<3D+hGmTLnuMJK~M|XF>@iWmtY2m$@ zB}ryU^47N%)>u3lxOgyN`|ZT=Wru0O`)*m@d;Fu|Di@shu?8M@0|G&$RgtWClqcfi ze<=e($dKj`hJyUm6Y0pKrS!h0ay8*1Vr{zpQ|WyUvNK)x9>FrEL9^E zo=P97TexpkJvxXTwmwCH_csZhz;wF$gXVgtY3(z_ta-9QUyK*sg#%pH4o4FiO%rPw zrb|(GD{(cI zD^g6dGg#4lHRfwrbRcLP?G=(y zKI$ZJ55M{EDkk>c(9*T;62Kh8F^Jj9giGKil=9r1Lz4JWp5Zp1$d_1G`r64w^=S>p z#7k^(^H+N85IsaP2lT<29uoPC5dwvr9?u_s8!JM|$v{61<5ZPEz^0cT$0<)z5r#u} zdTcfg-PQhV)!CQ;fbkK>v%a15ub7 zwapx5~_73kE0YP}91 z=b3hEm)tY4esm50vRv^Qfe?#;SM)Beh5yc{Q?)4*8`l%;%!D7gc@BwhGZ5;U%E#YZ zc90sid)~P`+Oo{8n>KpF1R@|h(b}f9KL{9YtL5IkGS#H@uuD@IA9u(f^2am&h6H$&jg-;WobsGKix5FZUe*$gc}z}*r6w;;*Wia4`C*np z^ASJPsHT!dVoo7IVAk>sQe0L>fQW)kxY83%0Pkl#e*D;4>5K%R;h1+efKR^@u7i); zC1Td5qMV1CtH~;==S=z5KCqXzN?bttFU1XC7Psl$QmqC{JB$_BA9m%)ii$BgW(nhf zcJ^$PZ$5LriC)=M^<{nT<(eF7Kh|HaKw~Dallf-br$2e__ijxYRCp3MK~McioIyZvPDOX=iF+X29Qno8VK-; zA3`l_I}UDezbF7sbkvmZ`|L;7%-m1gXxSX40KR=MH~BNn>%C7=3FN@|$Q0cG>Deg5 zS}^W?Tq&jW810To3e!TTyg2{k46B#&^2>8gY@`7AZyLiNe<*=Db*o^k-O!P1d?qKI zQ!f>c0yLVSrk4xwI$G_A0ovvpyzv`cadHeWHlf#f#7#Xb(GOkx47&Z6-xVIWA8e&R zN9T(h%6ZYL1`<1GzC%%w{BS4LJWRZY%!>;fT|uiWLO1vk;g#_$buvg28D`H*ucN+2 zq4|_3R}gSBdF7!yfUBk#qmiMUcikzE5AYMxdV<+X4PD@03V(*4&ZKZ)Ft^AB3}r2` zd@?U<3P|LVwzjO{0m6r?iAn<#l-=Fk*0I-sm&lN}?haSo2O@AElK$JjKR@Et(H~le zpZ}Q}dw(hh&Doi@nv6fr(FDgq;m8o_{nQtc?#8+5o;&#@M<*tp(LMQL5=7L?fgpNn zwHXH)Z;DV=LGo3!wn<%TDF3Gm+lb{u^vg{@c7mv`g|{!{E!R>%K=oQ4^P76^M8i| z-2~iH*8&LtEtj1js>uSoobbI`kZh*JqZT#) zEoJ(#gajtwVt&T4KGBrP`g($=DN9whAuxh5@`JTLU z_z&(xI*c>=gvR^JbPk$MM64xzZ-#F`AmBaq3{hpo@?B7ll=3_{yimhG{8uK#Wjq{A z+VgY@$)Gacv|2oJ{{sz&yp>XTQw)#f_&PXgGYy3w#5SxIt$j+~U(UYF&0|)uUCQu; zB_w)x18v)zl2=No{URq_2|*&-CMhMHMv58n(Eb#b<~OEiH4i^)?ej*`r>%t3uWf-A zcZ%=WIWgA>!VSp%mq7Z#T*{7zjt6O$fD6LFeya^s2zWBcdsrYsMC)(jL+G~Ef z2!wa?1QM#<{7*XTh^7}H;UfWcR;E9`a5_&pT)>C;aO1Gq!Qdm8q*UK#lrn~`KZ?5q8VrQ@4!tsc1&;~ zzp;)nAuYyKLZuE**fV1!4TCY2l@TKKHVlN1{Wsc{)y|=u!t|}$P6=d+xS0j`JXF`h z3-)dmwZ;#>Gcbp1sdzYM7br2*cBY6FPNq_P^ZtH5W&W*L)>g8i-y1jp9Ug%z93Eh4 zD~d4ziXZCDf3-v~NlGH!%th1oyW9k)e`O*o?XzIIAwUR&CkhOnj+OT-Gdo6)O}}83 zd`9Q9noB87`Guu#5EEp=i{w3dWK{It76hgi(4?h>JT@NI8(nMD=Ice^;G?j(2fqUF z-VkuSec4>DBy{|$Pukv^TrPTJ3lwI>!quA~zrGkg5xs+p0-!7(<#)(IVH?K?s?p>S zx)X(a;t^I1{l{J)(Zo+uLN?b37IYJG)qHXA!e(xjbBI1{wc}{~{%(r>u!I*m;_L-V zBtYGmKBA$frrPl%@dZRD#L)@d(q2$sB4d-0G^FGjKKlD3{I8Y@rhD)y&16=+9p$au z+u!hp642|T?%=BfR`MV(bubj+wRE!m0!yW5e5HwRo?#sqiH}?(el2<$aRU6jEX^^rXvkgZn8Ldju7)sV{GG0lr-5vR!qku)O- z#tYO>=+g)i`U{EyA|O%fg*BU})=LoWhf}3K!TfUVPppL>LejcQKwDR-u8u-N6`d=< zOAsc3@T%Ffu8kl(33<@h0It+9f93z`VTrGppKOeoN?F|=O71~B&qY3lu#bHPJPJLD z?wb$6tE_!$VKxzMZNGH@nAz`@;Hu2P)^n--1R3zxjo{*lb3DL!ExcjBG782O6J_Rx zQzyv({r+LSIS9h^QjG6Elc&OOUz)axwGv#P;&TrkF-Qfk5;gk$)`9c+bSo$uKjmOu z%UXl31fl6!8~q&1eXM389pqBJlsQgCG&s&Nt^)r1$1Q;Ck_BAT?)Gngk?=t+9XGu! zadR=kY5ywyW!|qUsU}EnG#DqjghfI&Mcj-s*EvpCgLo|9^O$#B={J=4TqUW&9XR*;il$FPV`Xtsbl?`9|5MZ+(ldFP8F2G zO*wzA!_9NGS)0vAmTNHz@Etlh)tGs?8RXc*bhNWxp`uZQUm3wSv^#(>ZiG9Xtr=5i z1mSB`q_EK~Ich?#;b1sRk^#CZ^$hkcZ@re!l%4ObWv^Mp=)>SfM0#Gh8PGtxzCdG? zjHE3H9=iA^X(*Z4P5C>@rIpIh-VD0Wzj4s-a~{NDsaN%`g8z=i{_^if&H^&fL%7_X z?BDMM4gFHgWK$RQQcaygkO@E(8&>Oiu=uB|AW5Sl!8828SIdgljjvpzjg85V{uW#T z&&W$OTIDL#yu8{s>JC4H#YRFe@#k%+nG1dHOIJa9b-lD#vS{1cb5D;b+9POXy+&1t3`8x z;KDBsYL#^`kH_kgX1UZ~D(1@3Z*tCh$R`z?Cg- z9>%ahXaA8YnYr!fl68)HN1Y!Ex%{+{4VAbRXu>gBJ>-hp(Of5=50*}Wnm$$Y;x~EL zrR4;gXB__rT4Y<^P zaVgv0?`uRZROLyis=LXC-`DyLY$K^puQdSf>fXT!97^Eb(8aq?yovb^j{pNO%69g_ z>Kj)BO{pL6Shl+6yvXPV7Na7d8`}E);%_fw+MfAWZjS2Q`@qXaPru;S$y{qy7d5Y) zgv(qdR<%Cr%R~uO=Ev-d$_v2GZVPS z`RBYxdyhV0oh);Eli%eJ_J{xT{dfKYypCfnuzhXItaxvMa=C#e)314lIE56iPmix( zU$O^yS6k7R+4tr3FVsamH{IUNe@-@R?GfPF!Ii)xCxzTf8W?!`1r-{qxxzLnK9y2D zVheZqllfg{KQI2?BOvsph2uQ`;p8oX^$hBAmEs$7N>g9jNq%fzy5>ZGJCkm~rQFjZ z$&!5sH)=$+oDlZmD)5^l-Iltk;74MFP^agSbF2EFMkGbrBVl}O-n-YwpSbM@UM$~n>|k~8MuSalESz(19oF2J8Q2Frd)vkPm2|X1!@cKj zh8I(Sllu7&gfH+f2Btofl76l()oo2Y+p7da;m5)7`SXs5NcZWWJbUdquVM+Ol})4duaI~#>$Jc zZR3l=#7MPcU52wKn~M1Y?td-3A=w3~lLaT$rrLakXlZh_3pg*%s<9z*GOax_%{R z>4Q{x{J7Z2_~Bs51&1xa6!L&mC!jldRbUa)!WL`6`0PyhQ_!#-P@*N~_?K>lkaQtn zg#}Xh4%((x33+kSYuTbQ3q{bi${d;9d?F{FaGAkWErNE~OkSuio!N2gVM_-{^N~Kk z_0v|0=0M$R)C|o(Ld~l3xnkyfDvi}$z_vsJOGU6-(_poi4#dmADhjH36IAnrIV!;2 zq_0zeN8P^q_U-PXUw=5aP6t`mvIKOl8Yp1uVQzlDV)q>dP~&3SNq#kt$y(gEd^)o9 zuB}uC2VaLYr~m|N{m2h3afA9o`E`hK-MF9XoNfw0S<+2_3Q9S zp63j<>pQS21gp@8so>c<{oJ-FJE^l5*e}`w`#h_ZK{vrWd04@0lZV;Xc2BiGLfxU` z*})~i8(o2>fQ}6VhsQry%=!fYYpgXA@%2jsw}O>S$N?5kAl8xj8Z&2rg{Vt#%FO?D a=l+V0D-5gpUXO@geCx2`EYvx diff --git a/base_classes/NXactuator.nxdl.xml b/base_classes/NXactuator.nxdl.xml deleted file mode 100644 index 3fe0a4108..000000000 --- a/base_classes/NXactuator.nxdl.xml +++ /dev/null @@ -1,127 +0,0 @@ - - - - - - An actuator used to control an external condition. - - The condition itself is described in :ref:`NXenvironment`. - - - - Actuator identification code/model number - - - - - Name of the actuator - - - - - Short name of actuator used e.g. on monitor display program - - - - - Describe where the actuator is attached to. - This could be an instance of NXsample or a device on NXinstrument. - - - - - Name for the physical quantity effected by the actuation - - Examples: - temperature | pH | magnetic_field | electric_field | current | conductivity | resistance | voltage | - pressure | flow | stress | strain | shear | surface_pressure - - - - - The type of hardware used for the actuation. - - Examples (suggestions, but not restrictions): - - :Temperature: laser | gas lamp | filament | resistive - :Pressure: anvil cell - :Voltage: potentiostat - - - - - Any output that the actuator produces. - For example, a heater can have the field heater_power(NX_FLOAT). - - - - - Time history of actuator outputs. - - - - - If the actuator is PID-controlled, the settings of the PID controller can be - stored here. - - - - Nominal actuator setpoint. - Can be a scalar or a vector (of [n] actuations). - - - - - Time history of actuator setpoints. - - - - - - Refers to the last transformation specifying the position of the actuator - in the NXtransformations chain. - - - - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the actuator within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - diff --git a/base_classes/NXapm_charge_state_analysis.nxdl.xml b/base_classes/NXapm_charge_state_analysis.nxdl.xml deleted file mode 100644 index e0adb7980..000000000 --- a/base_classes/NXapm_charge_state_analysis.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The number of also possible but different (molecular) ions. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - - - - - Number of entries - - - - - Base class to document an algorithm for recovering charge state and nuclide composition of a (molecular) ion. - - Currently ranging definitions in the research field of atom probe face have limitations: - - 1. A ranging definition maps all signal within a mass-to-charge-state-ratio value interval - on one iontype. Facing limited mass-resolving-power, there are mass-to-charge-state-ratio - values, though, for which not only multiple (molecular) ions are indistinguishable but - also for which the current practice of documenting classical ranging definitions is incomplete. - 2. Indeed, ranging definitions often report only (for each interval) the - mass-to-charge-state-ratio intervals surplus the composition of elements - that build the (molecular) ion. - 3. Therefore, classical ranging definitions demand a post-processing with an algorithm - which can identify nuclides from which the (molecular) ion is constructed - and a charge state possibly recovered. Combinatorial algorithms are used for this purpose. - - This base class documents the configuration and results of such an algorithm. - - - - - Input constraint, list of nuclide_hash for typically elements used for the - ranging definition of the ion whose charge state the analyses covered. - The list contains each hash as many times as its multiplicity. - Nuclides are encoded using the hashing rule that is defined in :ref:`NXion`. - - As an example, a ranging definition H:2 O:1 is configured by setting nuclides to - a list with entries :math:`1 + 0 \cdot 256`, :math:`1 + 0 \cdot 256`, :math:`8 + 0 \cdot 256`. - An empty list does not release the constraint. Instead, a list with all elements - in the periodic table (encoded as nuclide_hash values) should be used, i.e. - :math:`1 + 0 \cdot 256`, :math:`2 + 0 \cdot 256`, and so on and so forth. - - Keep in mind that with a weakly constrained parameter space the combinatorial - analysis may become very time consuming! - - - - - - - - Input constraint, interval within which (molecular) ions need to have the - mass-to-charge-state-ratio such that an ion qualifies as a candidate. - - - - - - - - - Input constraint, minimum half life for how long each nuclide of each - (molecular) ion needs to be stable such that the ion qualifies as a candidate. - - - - - Input constraint, minimum natural abundance of each nuclide of each - (molecular) ion such that the ion qualifies as a candidate. - - - - - If the value is false, it means that non-unique solutions are accepted. - These are solutions where multiple candidates have been built from - different nuclide instances but the charge_state of all the ions is the same. - - - - - - - Signed charge, i.e. integer multiple of the elementary - charge of each candidate. - - - - - - - - Table of nuclide instances of which each candidate is composed. - Each row vector is sorted in descending order. Unused values are nullified. - - - - - - - - - Accumulated mass of the nuclides in each candidate. - Not corrected for quantum effects. - - - - - - - - The product of the natural abundances of the nuclides for each candidate. - - - - - - - - For each candidate the half life of that nuclide which has the shortest half - life. - - - - - - diff --git a/base_classes/NXapm_hit_finding.nxdl.xml b/base_classes/NXapm_hit_finding.nxdl.xml deleted file mode 100644 index 534e3c7b0..000000000 --- a/base_classes/NXapm_hit_finding.nxdl.xml +++ /dev/null @@ -1,147 +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 - - - - - - - - Defines in which reference frame 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 fd1a52039..000000000 --- a/base_classes/NXapm_msr.nxdl.xml +++ /dev/null @@ -1,173 +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. - - - - - 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 30bdbb0fd..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/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index d1dea2e47..68fd0b414 100644 --- a/base_classes/NXbeam.nxdl.xml +++ b/base_classes/NXbeam.nxdl.xml @@ -61,45 +61,11 @@ Distance from sample. Note, it is recommended to use NXtransformations instead. - - Energy carried by each particle of the beam on entering the beamline component. - - In the case of a monochromatic beam this is the scalar energy. - Several other use cases are permitted, depending on the - presence of other incident_energy_X fields. - - * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. - * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. - Here, incident_energy_weights and incident_energy_spread are not set. - * In the case of a polychromatic beam that varies shot-to-shot, - this is an array of length m with the relative weights in incident_energy_weights as a 2D array. - * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, - this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. - - Note, variants are a good way to represent several of these use cases in a single dataset, - e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. - + Energy carried by each particle of the beam on entering the beamline component - - - The energy spread FWHM for the corresponding energy(ies) in incident_energy. In the case of shot-to-shot variation in - the energy spread, this is a 2D array of dimension nP by m - (slow to fast) of the spreads of the corresponding - wavelength in incident_wavelength. - - - - - In the case of a polychromatic beam this is an array of length m of the relative - weights of the corresponding energies in incident_energy. In the case of a - polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np - by m (slow to fast) of the relative weights of the corresponding energies in - incident_energy. - - Energy carried by each particle of the beam on leaving the beamline component @@ -194,9 +160,7 @@ Size of the beam entering this component. Note this represents - a rectangular beam aperture, and values represent FWHM. - If applicable, the first dimension shall be the horizontal extent - and the second dimension shall be the vertical extent. + a rectangular beam aperture, and values represent FWHM @@ -215,24 +179,6 @@ - - - The units for this observable are not included in the NIAC list. - Responsibility on correct formatting and parsing is handed to the user - by using `NX_ANY`. Correct parsing can still be implemented by using - this attribute. - - | Fill with: - - * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example: farad for capacitance). - * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and - does not have a name. - - Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). - Here: SI units are V2/m2. - - Polarization vector on leaving beamline component @@ -240,24 +186,6 @@ - - - The units for this observable are not included in the NIAC list. - Responsibility on correct formatting and parsing is handed to the user - by using `NX_ANY`. Correct parsing can still be implemented by using - this attribute. - - | Fill with: - - * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example: farad for capacitance). - * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and - does not have a name. - - Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). - Here: SI units are V2/m2. - - @@ -317,87 +245,6 @@ - - - Energy of a single pulse at the diagnostic point - - - - - Average power at the diagnostic point - - - - - Incident fluence at the diagnostic point - - - - Here: SI units are 'J/m2', customary 'mJ/cm2'. - - - - - - FWHM duration of the pulses at the diagnostic point - - - - - Delay time between two pulses of a pulsed beam. - - - - A reference to the beam in relation to which the delay is. - - - - - - FROG trace of the pulse. - - - - - - - - - Horizontal axis of a FROG trace, i.e. delay. - - - - - - - - Vertical axis of a FROG trace, i.e. frequency. - - - - - - - - The type of chirp implemented - - - - - Group delay dispersion of the pulse for linear chirp - - - - - Indicates the beam device from which this beam originates. - This defines, whether the beam in an "input" or "output" beam. - - - - - Gives the beam device which this beam will interact with next. - - Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly diff --git a/base_classes/NXbeam_device.nxdl.xml b/base_classes/NXbeam_device.nxdl.xml deleted file mode 100644 index ee798485f..000000000 --- a/base_classes/NXbeam_device.nxdl.xml +++ /dev/null @@ -1,67 +0,0 @@ - - - - - - Properties of generic beam device in an experimental setup. - - Any beam related devices like source, detector, filter, mirror, - beamsplitter, ... which may modifies a beam in an experimental setup - can be described here with its experimental position and relationship - to the other beam devices in the setup. - - - - Single device or list of devices pointing to the devices from which an - beam originated to reach this device. - This is used to describe a logical order of devices and for the whole setup. - In this way, a "beam path" can be described (i.e., with starting point (light source) - and end point (photo detector)). - - Example: /entry/instrument/detector. - - - - - Description of the intended purpose of this device for - the experimental setup. - - - - - Name of the group with which this device can be associated. - For example, if a group of devices is used for second harmonic generation, - all these devices have the group name "second harmonic generation". - Is used for simplified setup vizualization (or description?). - - - - - Location and orientation of the device. Note that even a - simple distance can be given as a translation. - - You can use the @depends_on to describe from which device - the transformation needs to be applied. - - - diff --git a/base_classes/NXbeam_transfer_matrix_table.nxdl.xml b/base_classes/NXbeam_transfer_matrix_table.nxdl.xml deleted file mode 100644 index d61f27556..000000000 --- a/base_classes/NXbeam_transfer_matrix_table.nxdl.xml +++ /dev/null @@ -1,120 +0,0 @@ - - - - - - - Variables used throughout the document, e.g. dimensions or parameters. - - - - Length of the array associated to the data type. - - - - - Contains datastructures of an experimental optical setup (i.e., multiple - transfermatrix tables). These datastructures are used to relate physical - properties of two beams (NXbeam) which have one common optical element - (NXopt_element) (one specific transfermatrix). - One of these beams in an input beam and the other one is an output beam. - - The data describes the change of beam properties, e.g. the intensity of a - beam is reduced because the transmission coefficient of the beam device is - lower than 1. - - - - Select which type of data was recorded, for example aperture and - focal length. - It is possible to have multiple selections. This selection defines - how many columns (N_variables) are stored in the data array. - N in the name, is the index number in which order the given - property is listed. - - - - - - - - - - - Please list in this array the column and row names used in your actual data. - That is in the case of aperture ['diameter'] or focal length ['focal_length_value'] - and for orientation matrix ['OM1', 'OM2', 'OM3'] or for jones matrix - ['JM1','JM2'] - - - - - - - - Contains the datastructure which relates beam properties of an - input and output beam as result of the input beam interaction - with the beam device. - - Transfermatrix relationship between N input beams and M output beams. - It contains a table with the relevant matricis to be used for different - transmissitted properties (such as polarization, intensity, phase). - - Data structure for all transfermatrices of an beam device in a setup. - For each combination of N input and M output beams and for L physical - concept (i.e. beam intensity), one matrix can be defined. - - In this way, the transfermatrix table has the dimension NxM. - - For each entry, in this transfermatrix, there are L formalisms. - Each formalism has the dimension math:`dim(L_i)xdim(L_i)`, - whereby math:`L_i` is the specific physical concept (Intensity, polarization, direction). - - A beamsplitter with two input laser beams can have a total of - four transfermatrices (2 Input x 2 Output). - - The dimension of the transfermatrix depends on the parameters. - Examples are: - 1x1 for intensity/power - 2x2 for jones formalism - 3x3 for direction - - - - Square matrix with dimension N_variables x N_variables - - - - - - - Specific name of input beam which the transfermatrix table is related to. - - - - - Specific name of output beam which the transfermatrix table is related to. - - - - diff --git a/base_classes/NXcalibration.nxdl.xml b/base_classes/NXcalibration.nxdl.xml deleted file mode 100644 index 702688fc2..000000000 --- a/base_classes/NXcalibration.nxdl.xml +++ /dev/null @@ -1,220 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - A description of the procedures employed. - - - - - The physical quantity of the calibration, e.g., - energy, momentum, time, etc. - - - - - A digital persistent identifier (e.g., DOI, ISO standard) referring to a detailed description of a - calibration method but no actual calibration data. - - - - - A digital persistent identifier (e.g., a DOI) referring to a publicly available calibration measurement - used for this instrument, e.g., a measurement of a known standard containing calibration information. - The axis values may be copied or linked in the appropriate NXcalibration fields for reference. - - - - - A file serialisation of a calibration which may not be publicly available (externally from the nexus file). - - This metadata can be a documentation of the source (file) or database (entry) from which pieces - of information have been extracted for consumption (e.g. in a research data management system (RDMS)). - It is also possible to include the actual file by using the `file` field. - - The axis values may be copied or linked in the appropriate NXcalibration fields for reference. - - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - Name of the software used for this calibration. - - - - Software version. - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. - This should comply to the following naming rules (similar to python's naming rules): - - * A variable name must start with a letter or the underscore character - * A variable name cannot start with a number - * A variable name can only contain alpha-numeric characters and underscores (A-z, 0-9, and _ ) - * Variable names are case-sensitive (age, Age and AGE are three different variables) - - - - - The path from which this data is derived, e.g., raw detector axis. - Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. - - - - - - Additional input axis to be used in the formula. - The part after `input_` is used as the symbol to be used in the `fit_function`, i.e., - if the field name is `input_my_field` you should refer to this axis by `my_field` in the `fit_function`. - - - - - - - The path from which this data is derived, e.g., raw detector axis. - Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. - - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the nth position in the `original_axis` field. - If there is the symbol attribute specified for the `original_axis` this may be used instead of x. - If you want to use the whole axis use `x`. - Alternate axis can also be available as specified by the `input_SYMBOL` field. - The data should then be referred here by the `SYMBOL` name, e.g., for a field - name `input_my_field` it should be referred here by `my_field` or `my_field0` if - you want to read the zeroth element of the array. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. - - - - - For linear calibration. Offset parameter. - This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. - - - - - Mapping data for calibration. - - This can be used to map data points from uncalibrated to calibrated values, - i.e., by multiplying each point in the input axis by the corresponding point in the mapping data. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - The path to which this data is written, e.g., the calibrated energy. - Should be a valid NeXus path name, e.g., /entry/data/energy. - - - - - - Any data acquired/used during the calibration that does not fit the `NX_FLOAT` fields above. - NXdata groups can be used for multidimensional data which are relevant to the calibration - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - diff --git a/base_classes/NXcg_face_list_data_structure.nxdl.xml b/base_classes/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index 081b928d5..000000000 --- a/base_classes/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,230 +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 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 - 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. - - 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. - - - - - Number of vertices for each face. - - Each entry represents the total number of vertices for that face, - irrespectively whether vertices are shared among faces or not. - - - - - - - - Number of edges for each face. - - Each entry represents the total number of edges for that face, - irrespectively whether edges are shared across faces or not. - - - - - - - - Number of faces of the primitives. - - - - - Integer offset whereby the identifier of the first member - of the vertices differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. - - - - - Integer offset whereby the identifier of the first member - of the edges differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. - - - - - Integer offset whereby the identifier of the first member - of the faces differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. - - - - - Integer identifier to distinguish all vertices explicitly. - - - - - - - - Integer used to distinguish all edges explicitly. - - - - - - - - Integer used to distinguish all faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to a unique set as this may - result in 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. - - - - - - - - - The edges are stored as pairs of vertex identifier. - - - - - - - - - The faces are stored as a concatenated array of vertex identifier tuples. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - - - - - - - - - If true, indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted more - than once. - - - - - If true, indicates that no edge is stored more than once. - - Users are encouraged to consider using a half_edge_data_structure instead. - - - - - If true, indicates that no face is stored more than once. - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/base_classes/NXcg_hexahedron_set.nxdl.xml b/base_classes/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 8ea85fb98..000000000 --- a/base_classes/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,193 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts an approach whereby - different specific views can be implemented using the same base class: - - * In the simplest case experimentalists may use this base class to describe - the dimensions or size of a specimen. In this case the alignment with axes - is not relevant as eventually only the volume of the specimen is of interest. - * In many cases, take for example an experiment where a specimen was cut out - from a specifically deformed piece of material, the orientation of the - specimen's edges with the experiment coordinate system is of high relevance. - Examples include knowledge about the specimen edge, whether it is - parallel to the rolling, the transverse, or the normal direction. - * While the above-mentioned use cases are sufficient to pinpoint the sample - within a known laboratory/experiment coordinate system, these descriptions - are not detailed enough to specify e.g. a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of hexahedra is offered to serve additional computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - As a specialization of the :ref:`NXcg_primitive_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 special cases cuboid, cube, box, axis-aligned bounding box (AABB), - and optimal bounding box (OBB). - - An axis-aligned bounding box is a common data object in computational science - and simulation codes to represent a cuboid whose edges are aligned with the - base vectors of a coordinate system. As a part of binary trees, these data - objects are important for making time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tightly fitting box about an arbitrary object. In general, such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist to compute optimal or near optimal bounding boxes for sets of points. - - - - - Qualifier for the shape of each hexahedron. - - - - - - - - - Qualifier that is useful in cases when one edge is longer than all other - edges of the hexahedra. Often the term length is associated with the - assumption that one edge is parallel to an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the extent of an object in the horizontal - direction assuming a specific coordinate system. - - For the sake of explicitness quantities like length, width, and height - should not be reported without specifying also the assumed reference frame. - - - - - - - - Qualifier often used to describe the extent of an object in the vertical - direction assuming a specific coordinate system. - - - - - - - - Volume of each hexahedron. - - - - - - - - Total (surface) area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the coordinate system. - - - - - - - - - - - - - Combined storage of all primitives of all hexahedra. - - - - - Individual storage of each hexahedron. - - - - - Individual storage of each hexahedron as a graph. - - - diff --git a/base_classes/NXcg_parallelogram_set.nxdl.xml b/base_classes/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index bfb868c47..000000000 --- a/base_classes/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,106 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms. - - This class can also be used to describe rectangles or squares, irrespective - whether these are axis-aligned or not. The class represents different - access and description levels to embrace applied scientists and computational - geometry experts with their different views: - - * The simplest case is the communication of dimensions aka the size of a - region of interest in the 2D plane. In this case, communicating the - alignment with axes is maybe not as relevant as it is to report the area - of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally, in CAD models it should be possible to specify the polygons - which the parallelograms represent with exact numerical details. - - Parallelograms are important geometrical primitives as their usage for - describing many scanning experiments shows where typically parallelogram-shaped - ROIs are scanned across the surface of a sample. - - The term parallelogram will be used throughout this base class thus including - the important special cases rectangle, square, 2D box, axis-aligned bounding box - (AABB), or optimal bounding box (OBB) as analogous 2D variants to their 3D - counterparts. See :ref:`NXcg_hexahedron_set` for the generalization in 3D. - - An axis-aligned bounding box is a common data object in computational science - and simulation codes to represent a rectangle whose edges are aligned with the - axes of a coordinate system. As a part of binary trees AABBs are important data - objects for executing time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best, i.e. - most tightly fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions, the rotation calipher method offers - a rigorous approach to compute an optimal bounding box to a point set in 2D. - - - - - To specify which parallelogram is a rectangle. - - - - - - - - Only to be used if is_rectangle is present. In this case, this field - describes whether parallelograms are rectangles whose primary edges - are parallel to the axes of the coordinate system. - - - - - - - - - - Combined storage of all primitives of all parallelograms. - - - - - Individual storage of each parallelogram. - - - - diff --git a/base_classes/NXcg_point_set.nxdl.xml b/base_classes/NXcg_point_set.nxdl.xml deleted file mode 100644 index c2190590d..000000000 --- a/base_classes/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points. - - Points may have an associated time value. Users are advised though to store - time data of point sets rather as instances of time events, where for each - point in time there is an :ref:`NXcg_point_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. - - - - Coordinates of the points. - - - - - - - - - (Elapsed) time for each point. - - If the field time is needed contextualize the time_offset relative to which - time values are defined. Alternative store timestamp. - - - - - - - - ISO8601 with local time zone offset for each point. - - - - - - - - ISO8601 with local time zone offset that serves as the reference - for values in the field time. - - - diff --git a/base_classes/NXcg_polygon_set.nxdl.xml b/base_classes/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index 95c157ce1..000000000 --- a/base_classes/NXcg_polygon_set.nxdl.xml +++ /dev/null @@ -1,131 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific :ref:`NXcg_polyhedron_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 instead of abusing this base class for such purposes. - - - - The total number of vertices in the set. - - - - - - Combined storage of all primitives of all polygons. - - - - - Individual storage of the mesh of each polygon. - - - - - Individual storage of each polygon as a graph. - - - - - - For each polygon its accumulated length along its edges. - - - - - - - - Interior angles for each polygon. There are as many values per polygon - as the are number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - diff --git a/base_classes/NXcg_polyhedron_set.nxdl.xml b/base_classes/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index b087b0c79..000000000 --- a/base_classes/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,114 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a set of polyhedra in Euclidean space. - - Polyhedra or so-called cells (especially in the convex of tessellations) are - constructed from polygon meshes. Polyhedra may make contact to allow a usage - of this base class for a description of tessellations. - - For the description of more complicated manifolds and especially for polyhedra - with holes, users are advised to check if their particular needs are described - by creating customized instances of an :ref:`NXcg_polygon_set`. - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. - - - - - - - - Area of each of faces. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. - - - - - Length of each edge. - - - - - - - - - Combined storage of all primitives of all polyhedra. - - - - - Individual storage of each polyhedron. - - - - - Individual storage of each polygon as a graph. - - - diff --git a/base_classes/NXcg_primitive_set.nxdl.xml b/base_classes/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index 034216a3e..000000000 --- a/base_classes/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/base_classes/NXcg_roi_set.nxdl.xml b/base_classes/NXcg_roi_set.nxdl.xml deleted file mode 100644 index 69bc0042e..000000000 --- a/base_classes/NXcg_roi_set.nxdl.xml +++ /dev/null @@ -1,57 +0,0 @@ - - - - - - - - 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 for a region-of-interest (ROI) bound by geometric primitives. - - So-called region-of-interest(s) (ROIs) are typically used to describe a - region in space (and time) where an observation is made or for which - a computer simulation is performed with given boundary conditions. - - - - - - - - - diff --git a/base_classes/NXcg_tetrahedron_set.nxdl.xml b/base_classes/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index 509347c51..000000000 --- a/base_classes/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,86 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra. - - Among hexahedral elements, tetrahedral elements are one of the most - frequently used geometric primitive for meshing and describing volumetric - objects in continuum-field simulations. - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - - Combined storage of all primitives of all tetrahedra. - - - - - Individual storage of each tetrahedron. - - - - - Individual storage of each tetrahedron as a graph. - - - diff --git a/base_classes/NXcg_triangle_set.nxdl.xml b/base_classes/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index 7d994eb3e..000000000 --- a/base_classes/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles. - - - - Number of unique vertices in the triangle set. - - - - - Combined storage of all primitives of all triangles. - - This description resembles the typical representation of primitives - in file formats such as OFF, PLY, VTK, or STL. - - - - - Individual storage of each triangle. - Users are advised that using such individual storage of primitives - may be less storage efficient than creating a combined storage. - - - - - - Length of the edges of each triangle. - - For each triangle values are reported via traversing - the vertices in the sequence as these are defined. - - - - - - - - - Interior angles of each triangle. - - For each triangle values are reported for the angle opposite - to the respective edges in the sequence how vertices are defined. - - - - - - - diff --git a/base_classes/NXchemical_process.nxdl.xml b/base_classes/NXchemical_process.nxdl.xml deleted file mode 100644 index 437fcf0b6..000000000 --- a/base_classes/NXchemical_process.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - A planned or unplanned process which results in chemical changes (i.e., changes in the chemical bonds) in a specified material. - - Examples include any chemical reactions (addition, subtraction, replacement, ...). - - - - ISO 8601 formatted time code (with local time zone offset to UTC information - included) when this process started. - - - - - ISO 8601 formatted time code (with local time zone offset to UTC information - included) when this process ended. - - - - - Short description of the chemical process. - - - - - Method by which this process was performed. - - - - - This can be any data or other descriptor acquired during the chemical process - (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - diff --git a/base_classes/NXcircuit.nxdl.xml b/base_classes/NXcircuit.nxdl.xml deleted file mode 100644 index 9648ae103..000000000 --- a/base_classes/NXcircuit.nxdl.xml +++ /dev/null @@ -1,136 +0,0 @@ - - - - - - Base class for circuit devices. - - - - Hardware type used in circuit, includes hardware manufacturers and type - - - - - The tunneling current between tip and sample after application of bias voltage. - - - - - Calibration of the current measurement (A/V). - - - - - Offset of the current measurement. - - - - - Proportional relationship between the probe output voltage and the actual - tunneling current when measuring the tunneling current. - - - - - The scan channels are selected by users (in scan contronaller). - - - - - The bandwitdh of the Hardware and/or Software - - - - - (Signals Periods) The Signals Period is the rate at which the signals are - transferred to the host computer running the control software. This is usually - lower by a factor of 10 than the sampling rate, because an internal oversampling - of the signal is done on the real time engine. You can reduce the oversampling - down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. - - - - - Update rate for several processes like History Graph, Auto-Approach, and for - many Programming Interface functions. This is usually set to 20 ms. All - additional timings (7-9) can only be integer multiples of this value. They can - be set to different values, but the actual timing value will be coerced to a - multiple of the Acquisition Period. - - - - - Update rate of animated graphical indicators. These are e.g. some graphs & - sliders. A reasonable value is 40 ms (25 updates per second). Increase this - period to reduce the processor load for the graphical user interface, especially - on slow computers. This value is purely a user interface update rate and does - not affect measurements in any way. - - - - - Update rate of digital indicators, e.g. the numbers displayed besides each - slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a - user interface update rate and does not affect measurements in any way. - - - - - The Measurements period is the integration time for precise measurements - (averaging over specified period), mostly used in sweep modules. Examples are - recording of a force-distance curve or a resonance of a cantilever. For fast - measurements with small steps, a value of 40 ms may be reasonable. For normal - use, 300-500 ms is a good value, but for recording a resonance of a high-Q - cantilever, values of several seconds might be necessary. Usually this parameter - doesn’t need to be set from this module; the sweep modules will set this value - according to the sweep timings. - - - - - Number of output channels - - - - - The user output in each monitor mode. - - - - - The values for each output channel. - - - - - User outputs whose name can be modified in the corresponding module. - - - - - The rate at which the one of the signal changes when ramping to the starting - point. (V/s) - - - diff --git a/base_classes/NXcomponent.nxdl.xml b/base_classes/NXcomponent.nxdl.xml deleted file mode 100644 index d317db680..000000000 --- a/base_classes/NXcomponent.nxdl.xml +++ /dev/null @@ -1,64 +0,0 @@ - - - - - - Base class for components of an instrument - real ones or a simulated ones. - - - - Specifies the position of the component by pointing to the last - transformation in the transformation chain that is defined - via the NXtransformations group. - - - - - Was the component used? - - - - - Given name - - - - - Ideally, use instances of :ref:`NXidentifier` to point to a resource - that provides further details. - - If such a resource does not exist or should not be used, use this, though - discouraged, free-text. - - - - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. - - - - diff --git a/base_classes/NXcoordinate_system.nxdl.xml b/base_classes/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 80de81f40..000000000 --- a/base_classes/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,159 +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 third axis which spans the coordinate system. - This axis is frequently referred to as the z-axis in real space and - the k-axis in reciprocal space. - - - - - - - - This specificies the relation to another coordinate system by pointing to the last - transformation in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe this coordinate system - with respect to another coordinate system. - - - diff --git a/base_classes/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml deleted file mode 100644 index a842d257d..000000000 --- a/base_classes/NXcoordinate_system_set.nxdl.xml +++ /dev/null @@ -1,240 +0,0 @@ - - - - - - - Base class to hold different coordinate systems and representation conversions. - - How many nodes of type :ref:`NXcoordinate_system_set` should be used in an application definition? - - * 0; if there is no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across - the application definition, an instance of NXcoordinate_system is defined, - the default NeXus `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ - coordinate system is assumed. This makes :ref:`NXcoordinate_system_set` and - NXcoordinate_system base classes backwards compatible to older - NeXus conventions and classes. - * 1; if only one :ref:`NXcoordinate_system_set` is defined, it should be placed - as high up in the node hierarchy (ideally right below an instance of NXentry) - of the application definition tree as possible. - This :ref:`NXcoordinate_system_set` should define at least one NXcoordinate_system - instance. This shall be named such that it is clear how this coordinate system is - typically referred to in a community. For the NeXus `McStas coordinate system, it is - advised to call it mcstas for the sake of improved clarity. - Additional NXcoordinate_system instances should be specified if possible in that same - :ref:`NXcoordinate_system_set` instead of cluttering them across the tree. - - If this is the case, it is assumed that the NXcoordinate_system_members - overwrite the NeXus default McStas coordinate system, i.e. users can thereby - conveniently and explicitly specify the coordinate system(s) that - they wish to use. - - Users are encouraged to write also explicit and clean depends_on fields in - all groups that encode information about where the interpretation of coordinate - systems is relevant. If these depends_on hints are not provided, it is - automatically assumed that all children (to arbitrary depth) - of that branch and sub-branches below the one in which that - :ref:`NXcoordinate_system_set` is defined use either the only NXcoordinate_system_set - instance in that set or the application definition is considered - underconstrained which should at all costs be avoided and in which case - again McStas is assumed. - * 2 and more; as soon as more than one :ref:`NXcoordinate_system_set` is specified - somewhere in the tree, different interpretations are possible as to which - of these coordinate system sets and instances apply or take preference. - We realize that such ambiguities should at all costs be avoided. - However, the opportunity for multiple sets and their instances enables to - have branch-specific coordinate system conventions which could especially - be useful for deep classes where multiple scientific methods are combined or - cases where having a definition of global translation and conversion tables - how to convert between representations in different coordinate systems - is not desired or available for now. - We argue that having 2 or more :ref:`NXcoordinate_system_set` instances and respective - NXcoordinate_system instances makes the interpretation eventually unnecessary - complicated. Instead, developers of application definitions should always try - to work for clarity and thus use only one top-level coordinate system set. - - For these reasons we conclude that the option with one top-level - :ref:`NXcoordinate_system_set` instance is the preferred choice. - - McStas is used if neither an instance of :ref:`NXcoordinate_system_set` nor an instance - of NXcoordinate_system is specified. However, even in this case it is better - to be explicit like for every other coordinate system definition to support - users with interpreting the content and logic behind every instance of the tree. - - How to store coordinate systems inside :ref:`NXcoordinate_system_set`? - Individual coordinate systems should be specified as members of the - :ref:`NXcoordinate_system_set` instance using instances of NXcoordinate_system. - - How many individual instances of NXcoordinate_system to allow within one - instance of :ref:`NXcoordinate_system_set`? - - * 0; This case should be avoided for the sake of clarity but this case could - mean the authors of the definition meant that McStas is used. We conclude, - McStas is used in this case. - * 1; Like above-mentioned this case has the advantage that it is explicit - and faces no ambiguities. However, in reality typically multiple - coordinate systems have to be mastered especially for complex - multi-signal modality experiments. - * 2 or more; If this case is realized, the best practice is that in every - case where a coordinate system should be referred to the respective class - has a depends_on field which resolves the possible ambiguities which specific - coordinate systems is referred to. The benefit of this explicit and clear - specifying of the coordinate system used in every case is that especially - in combination with having coordinate systems inside deeper branches - makes up for a very versatile, backwards compatible, but powerful system - to express different types of coordinate systems using NeXus. In the case - of two or more instances of NXcoordinate_system in one :ref:`NXcoordinate_system_set`, - it is also advised to specify the relationship between the two coordinate systems by - using the (NXtransformations) group within NXcoordinate_system. - - In effect, 1 should be the preferred choice. However, if more than one coordinate - system is defined for practical purposes, explicit depends_on fields should - always guide the user for each group and field which of the coordinate system - one refers to. - - - - Convention how a positive rotation angle is defined when viewing - from the end of the rotation unit vector towards its origin, - i.e. in accordance with convention 2 of - DOI: 10.1088/0965-0393/23/8/083501. - Counter_clockwise is equivalent to a right-handed choice. - Clockwise is equivalent to a left-handed choice. - - - - - - - - - - How are rotations interpreted into an orientation - according to convention 3 of - DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - - How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) - according to convention 4 of DOI: 10.1088/0965-0393/23/8/083501. - - The most frequently used convention is zxz, which is based on the work of H.-J. Bunge - but other conventions are possible. Apart from undefined, proper Euler angles - are distinguished from (improper) Tait-Bryan angles. - - - - - - - - - - - - - - - - - - - - To which angular range is the rotation angle argument of an - axis-angle pair parameterization constrained according to - convention 5 of DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - Which sign convention is followed when converting orientations - between different parameterizations/representations according - to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - - - - - Details about eventually relevant named directions that may give reasons for anisotropies. - The classical example is mechanical processing where one has to specify which directions - (e.g. rolling, transverse, and normal direction) align how with the direction of the base - vectors of the sample_reference_frame. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the - base vectors of this coordinate system as Xp, Yp, Zp. - - - - - Details about the sample_reference_frame that is typically overlaid onto the surface of the sample. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the - base vectors of this coordinate system as Xs, Ys, Zs. - - - - - Details about the detector_reference_frame for a specific detector. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the - base vectors of this coordinate system as Xd, Yd, Zd. - - It is assumed that the configuration is inspected by looking towards the sample surface - from a position that is located behind the detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index a6f57819b..000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,221 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of images taken, at least one. - - - - - Base class for a corrector reducing (spherical) aberrations in electron microscopy. - - Different technology partners use different naming schemes and - models for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses - and multipole stigmators with details specific for the technology partner - and microscope. Many of their technical details is proprietary knowledge. - - If functionalities for correcting multiple aberrations are included in - one :ref:`NXcomponent` `like it is reported here <https://www.ceos-gmbh.de/en/research/electrostat>`_ - use multiple groups: - - * :ref:`NXcorrector_cs` for spherical aberration - * :ref:`NXmonochromator` for energy filtering or chromatic aberration - * corrector_ax in :ref:`NXem` for axial astigmatism correction - - - - - Was the corrector used? - - - - - - Specific information about the alignment procedure that is a process during which - the corrector is configured to enable calibrated usage of the instrument. - - This :ref:`NXprocess` group should also be used when one describes in a computer - simulation the specific details about the modelled or assumed aberration - corrections. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau acquisition. - - TODO: The relevant axes which span the tilt_angle need a - cleaner description. - - - - - - - - The exposure time of single tilt images. - - - - - - - - The factor of enlargement of the apparent size, - not the physical size, of an object. - - - - - - - - The images taken during the alignment procedure. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) - for different definitions available and further details. Table 7-2 of Ibid. publication (page 305ff) documents how - to convert from the Nion to the CEOS definitions. Conversion tables are also summarized by `Y. Liao <https://www.globalsino.com/EM/page3740.html>`_. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXcrystal_structure.nxdl.xml b/base_classes/NXcrystal_structure.nxdl.xml deleted file mode 100644 index e01993be3..000000000 --- a/base_classes/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,274 +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. - - - - Details 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. - - - - - - - - Details the reference frame in which the positions are defined. - - - - - - - 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 6303eb3ae..000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,146 +0,0 @@ - - - - - - Base class for reporting the description of a computer - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - Details about the system of processing units e.g. (classical) processing units (CPUs), - coprocessor, graphic cards, accelerator processing units or a system of these. - - - - Granularizing the processing units. Typical examples, a desktop computer - with a single CPU one could describe using one instance of NXcircuit. - A dual-socket server one could describe using two instances NXcircuit - A server with two dual-socket server nodes one could describe with - four instances of NXcircuit surplus a field with their level in the hierarchy. - - - - General type of the processing unit - - - - - - - - - - - Given name - - - - - - - Details about the memory system. - - - - Granularizing the components of the memory system. - - - - Qualifier for the type of random access memory. - - - - - - - - - Total amount of data which the medium can hold. - - - - - Given name - - - - - - - Details about the I/O system. - - - - Granularizing the components of the I/O system. - - - - Qualifier for the type of storage medium used. - - - - - - - - - - Total amount of data which the medium can hold. - - - - - Given name - - - - - - diff --git a/base_classes/NXdata.nxdl.xml b/base_classes/NXdata.nxdl.xml index 8b445f1e2..9562baa93 100644 --- a/base_classes/NXdata.nxdl.xml +++ b/base_classes/NXdata.nxdl.xml @@ -309,20 +309,6 @@ - - - Points to the path of a field defining the data to which the `DATA` group refers. - - This concept allows to link the data to a respective field in the NeXus hierarchy, thereby - defining the physical quantity it represents. - - Example: - If the data corresponds to a readout of a detector, ``@reference`` links - to that detectors data: - - @reference: '/entry/instrument/detector/data' for a 2D detector - - - - - Electronic level probed in X-ray spectroscopy or resonance experiments. - - - - Symbol of the chemical element. - - For each, the atomic number, common English name, and standard atomic weight are also given. - - - - - Z=1, name="hydrogen", standard_atomic_weight=1.0078 - - - - - Z=2, name="helium", standard_atomic_weight=4.0026 - - - - - Z=3, name="lithium", standard_atomic_weight=6.94 - - - - - Z=4, name="beryllium", standard_atomic_weight=9.0122 - - - - - Z=5, name="boron", standard_atomic_weight=10.81 - - - - - Z=6, name="carbon", standard_atomic_weight=12.011 - - - - - Z=7, name="nitrogen", standard_atomic_weight=14.007 - - - - - Z=8, name="oxygen", standard_atomic_weight=15.999 - - - - - Z=9, name="fluorine", standard_atomic_weight=18.9984 - - - - - Z=10, name="neon", standard_atomic_weight=20.1797 - - - - - Z=11, name="sodium", standard_atomic_weight=22.9898 - - - - - Z=12, name="magnesium", standard_atomic_weight=24.305 - - - - - Z=13, name="aluminum", standard_atomic_weight=26.9815 - - - - - Z=14, name="silicon", standard_atomic_weight=28.085 - - - - - Z=15, name="phosphorus", standard_atomic_weight=30.9738 - - - - - Z=16, name="sulfur", standard_atomic_weight=32.06 - - - - - Z=17, name="chlorine", standard_atomic_weight=35.453 - - - - - Z=18, name="argon", standard_atomic_weight=39.948 - - - - - Z=19, name="potassium", standard_atomic_weight=39.0983 - - - - - Z=20, name="calcium", standard_atomic_weight=40.078 - - - - - Z=21, name="scandium", standard_atomic_weight=44.9559 - - - - - Z=22, name="titanium", standard_atomic_weight=47.867 - - - - - Z=23, name="vanadium", standard_atomic_weight=50.9415 - - - - - Z=24, name="chromium", standard_atomic_weight=51.996 - - - - - Z=25, name="manganese", standard_atomic_weight=54.938 - - - - - Z=26, name="iron", standard_atomic_weight=55.845 - - - - - Z=27, name="cobalt", standard_atomic_weight=58.9332 - - - - - Z=28, name="nickel", standard_atomic_weight=58.6934 - - - - - Z=29, name="copper", standard_atomic_weight=63.546 - - - - - Z=30, name="zinc", standard_atomic_weight=65.38 - - - - - Z=31, name="gallium", standard_atomic_weight=69.72 - - - - - Z=32, name="germanium", standard_atomic_weight=72.63 - - - - - Z=33, name="arsenic", standard_atomic_weight=74.9216 - - - - - Z=34, name="selenium", standard_atomic_weight=78.971 - - - - - Z=35, name="bromine", standard_atomic_weight=79.904 - - - - - Z=36, name="krypton", standard_atomic_weight=83.798 - - - - - Z=37, name="rubidium", standard_atomic_weight=85.4678 - - - - - Z=38, name="strontium", standard_atomic_weight=87.62 - - - - - Z=39, name="yttrium", standard_atomic_weight=88.9058 - - - - - Z=40, name="zirconium", standard_atomic_weight=91.224 - - - - - Z=41, name="niobium", standard_atomic_weight=92.9064 - - - - - Z=42, name="molybdenum", standard_atomic_weight=95.95 - - - - - Z=43, name="technetium", standard_atomic_weight=97.907 - - - - - Z=44, name="ruthenium", standard_atomic_weight=101.07 - - - - - Z=45, name="rhodium", standard_atomic_weight=102.906 - - - - - Z=46, name="palladium", standard_atomic_weight=106.42 - - - - - Z=47, name="silver", standard_atomic_weight=107.868 - - - - - Z=48, name="cadmium", standard_atomic_weight=112.414 - - - - - Z=49, name="indium", standard_atomic_weight=114.818 - - - - - Z=50, name="tin", standard_atomic_weight=118.71 - - - - - Z=51, name="antimony", standard_atomic_weight=121.76 - - - - - Z=52, name="tellurium", standard_atomic_weight=127.6 - - - - - Z=53, name="iodine", standard_atomic_weight=126.905 - - - - - Z=54, name="xenon", standard_atomic_weight=131.293 - - - - - Z=55, name="cesium", standard_atomic_weight=132.905 - - - - - Z=56, name="barium", standard_atomic_weight=137.327 - - - - - Z=57, name="lanthanum", standard_atomic_weight=138.905 - - - - - Z=58, name="cerium", standard_atomic_weight=140.116 - - - - - Z=59, name="praseodymium", standard_atomic_weight=140.908 - - - - - Z=60, name="neodymium", standard_atomic_weight=144.242 - - - - - Z=61, name="promethium", standard_atomic_weight=145.0 - - - - - Z=62, name="samarium", standard_atomic_weight=150.36 - - - - - Z=63, name="europium", standard_atomic_weight=151.96 - - - - - Z=64, name="gadolinium", standard_atomic_weight=157.25 - - - - - Z=65, name="terbium", standard_atomic_weight=158.925 - - - - - Z=66, name="dysprosium", standard_atomic_weight=162.5 - - - - - Z=67, name="holmium", standard_atomic_weight=164.93 - - - - - Z=68, name="erbium", standard_atomic_weight=167.259 - - - - - Z=69, name="thulium", standard_atomic_weight=168.934 - - - - - Z=70, name="ytterbium", standard_atomic_weight=173.045 - - - - - Z=71, name="lutetium", standard_atomic_weight=174.967 - - - - - Z=72, name="hafnium", standard_atomic_weight=178.49 - - - - - Z=73, name="tantalum", standard_atomic_weight=180.948 - - - - - Z=74, name="tungsten", standard_atomic_weight=183.84 - - - - - Z=75, name="rhenium", standard_atomic_weight=186.207 - - - - - Z=76, name="osmium", standard_atomic_weight=190.23 - - - - - Z=77, name="iridium", standard_atomic_weight=192.217 - - - - - Z=78, name="platinum", standard_atomic_weight=195.084 - - - - - Z=79, name="gold", standard_atomic_weight=196.967 - - - - - Z=80, name="mercury", standard_atomic_weight=200.592 - - - - - Z=81, name="thallium", standard_atomic_weight=204.383 - - - - - Z=82, name="lead", standard_atomic_weight=207.2 - - - - - Z=83, name="bismuth", standard_atomic_weight=208.98 - - - - - Z=84, name="polonium", standard_atomic_weight=209.0 - - - - - Z=85, name="astatine", standard_atomic_weight=210.0 - - - - - Z=86, name="radon", standard_atomic_weight=222.0 - - - - - Z=87, name="francium", standard_atomic_weight=223.0 - - - - - Z=88, name="radium", standard_atomic_weight=226.0 - - - - - Z=89, name="actinium", standard_atomic_weight=227.0 - - - - - Z=90, name="thorium", standard_atomic_weight=232.038 - - - - - Z=91, name="protactinium", standard_atomic_weight=231.036 - - - - - Z=92, name="uranium", standard_atomic_weight=238.029 - - - - - Z=93, name="neptunium", standard_atomic_weight=237.048 - - - - - Z=94, name="plutonium", standard_atomic_weight=239.052 - - - - - Z=95, name="americium", standard_atomic_weight=243.0 - - - - - Z=96, name="curium", standard_atomic_weight=247.0 - - - - - Z=97, name="berkelium", standard_atomic_weight=247.0 - - - - - Z=98, name="californium", standard_atomic_weight=251.0 - - - - - Z=99, name="einsteinium", standard_atomic_weight=252 - - - - - Z=100, name="fermium", standard_atomic_weight=257 - - - - - Z=101, name="mendelevium", standard_atomic_weight=258 - - - - - Z=102, name="nobelium", standard_atomic_weight=259 - - - - - Z=103, name="lawrencium", standard_atomic_weight=266 - - - - - Z=104, name="rutherfordium", standard_atomic_weight=267 - - - - - Z=105, name="dubnium", standard_atomic_weight=268 - - - - - Z=106, name="seaborgium", standard_atomic_weight=269 - - - - - Z=107, name="bohrium", standard_atomic_weight=270 - - - - - Z=108, name="hassium", standard_atomic_weight=269 - - - - - Z=109, name="meitnerium", standard_atomic_weight=278 - - - - - Z=110, name="darmstadtium", standard_atomic_weight=281 - - - - - Z=111, name="roentgenium", standard_atomic_weight=282 - - - - - Z=112, name="copernicium", standard_atomic_weight=285 - - - - - Z=113, name="nihonium", standard_atomic_weight=286 - - - - - Z=114, name="flerovium", standard_atomic_weight=289 - - - - - Z=115, name="moscovium", standard_atomic_weight=290 - - - - - Z=116, name="livermorium", standard_atomic_weight=293 - - - - - Z=117, name="tennessine", standard_atomic_weight=294 - - - - - Z=118, name="oganesson", standard_atomic_weight=294 - - - - - - - IUPAC symbol of the electronic level. - For each level, the electronic orbital configuration is also given - - For reference, see Jenkins, R., Manne, R., Robin, R., & Senemaud, C. (1991). - IUPAC—nomenclature system for x-ray spectroscopy. X-Ray Spectrometry, 20(3), 149-155. - - - - - same as 1s in level_xray - - - - - 2s - - - - - 2p_{1/2} - - - - - 2p_{3/2} - - - - - 3s - - - - - 3p_{1/2} - - - - - 3p_{3/2} - - - - - 3d_{3/2} - - - - - 3d_{5/2} - - - - - 4s - - - - - 4p_{1/2} - - - - - 4p_{3/2} - - - - - 4d_{3/2} - - - - - 4d_{5/2} - - - - - 4f_{5/2} - - - - - 4f_{7/2} - - - - - 5s - - - - - 5p_{1/2} - - - - - 5p_{3/2} - - - - - 5d_{3/2} - - - - - 5d_{5/2} - - - - - 5f_{5/2} - - - - - 5f_{7/2} - - - - - 6s - - - - - 6p_{1/2} - - - - - 6p_{3/2} - - - - - - - Electronic orbital configuration of the electronic level. - - - - - same as K in level_xray - - - - - L1 - - - - - L3 - - - - - M1 - - - - - M2 - - - - - M3 - - - - - M4 - - - - - M5 - - - - - N1 - - - - - N2 - - - - - N3 - - - - - N4 - - - - - N5 - - - - - N6 - - - - - N7 - - - - - O1 - - - - - O2 - - - - - O3 - - - - - O4 - - - - - O5 - - - - - O6 - - - - - O7 - - - - - P1 - - - - - P2 - - - - - P3 - - - - - - - description of X-ray electronic level - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - diff --git a/base_classes/NXelectronanalyser.nxdl.xml b/base_classes/NXelectronanalyser.nxdl.xml deleted file mode 100644 index 096e8351a..000000000 --- a/base_classes/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,310 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired simultaneously, without scanning a - physical quantity) - - - - - Number of slow axes (axes acquired scanning a physical quantity) - - - - - Number of data points in the transmission function. - - - - - Basic class for describing a electron analyzer. - - This concept is related to term `12.59`_ of the ISO 18115-1:2023 standard. - - .. _12.59: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Work function of the electron analyser. - - The work function of a uniform surface of a conductor is the minimum energy required to remove - an electron from the interior of the solid to a vacuum level immediately outside the solid surface. - - The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with binding energy - :math:`E_B` below the Fermi level is given by :math:`E_K = h\nu - E_B - W = h\nu - E_B - e \phi_{\mathrm{sample}}`. - Here, :math:`W = e \phi_{\mathrm{sample}}` is the work function of the sample surface (with the potential difference :math:`\phi_{\mathrm{sample}}` - between the electrochemical potential of electrons in the bulk and the electrostatic potential of an electron in the vacuum just outside the surface). - - In PES measurements, the sample and the spectrometer (with work function :math:`\phi_{\mathrm{spectr.}}`) - are electrically connected and therefore their Fermi levels are aligned. Due to the difference in local - vacuum level between the sample and spectrometer, there exists an electric potential difference (contact potential) - :math:`\Delta\phi = \phi_{\mathrm{sample}} - \phi_{\mathrm{spectr.}}`. The measured kinetic energy of - a photoelectron in PES is therefore given by - :math:`E_K^{\mathrm{meas.}} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_{\mathrm{spectr.}}`. - As a result, the measured kinetic energy :math:`E_K^{\mathrm{meas.}}` of a photoelectron is `independent` - of the sample work function. Nonetheless, the work function :math:`\phi_s` needs to be known to - accurately determine the binding energy scale. - - - - - Energy range of the voltage supplies. This influences the noise of the supplies, - and thereby the energy resolution. - - - - - Energy resolution of the analyser with the current setting. May be linked from an - NXcalibration. - - - - - - - - - Minimum distinguishable energy separation in the energy spectra. - - This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. - - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - - - - - - Ratio of the energy resolution of the electron analyser at a specified energy - value to that energy value. - - This concept is related to term `10.7`_ of the ISO 18115-1:2023 standard. - - .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - - - - - - - - Angular resolution of the electron analyser (FWHM) - - - - - - - - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - This concept is related to term `10.14`_ of the ISO 18115-1:2023 standard. - - .. _10.14: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.15 - - - - - - - - - - - - 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. - - - - - - - - Transmission function of the electron analyser. - - The transmission function (TF) specifies the detection efficiency per solid angle for electrons of - different kinetic energy passing through the electron analyser. It depends on the spectrometer - geometry as well as operation settings such as lens mode and pass energy. - The transmission function is usually given as relative intensity vs. kinetic energy. - - The TF is used for calibration of the intensity scale in quantitative XPS. Without proper - transmission correction, a comparison of results measured from the same sample using different - operating modes for an instrument would show significant variations in atomic - concentrations. - - This concept is related to term `7.15`_ of the ISO 18115-1:2023 standard. - - .. _7.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.15 - - - - - - - - - - - - - - Kinetic energy values - - - - - - - - Relative transmission efficiency for the given kinetic energies - - - - - - - - - Refers to the last transformation specifying the position of the electron analyser - 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. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - - 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 ensembles described by the subclasses - - - - - Individual lenses outside the main optics ensembles described by the subclasses - - - - - - Any other resolution not explicitly named in this base class. - - - diff --git a/base_classes/NXem_correlation.nxdl.xml b/base_classes/NXem_correlation.nxdl.xml deleted file mode 100644 index 14cf17914..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 NXmicrostructure partner application - definition. The respective source of the data in an instance of NXmicrostructure 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 a1926fef4..000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,712 +0,0 @@ - - - - - - - - Number of arguments per orientation for given parameterization. - - - - - Number of scan points. - - - - - Number of pixel along the slowest changing dimension for a rediscretized, - i.e. standardized default plot orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default plot orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default plot orientation mapping. - - - - - Number of phase solutions - - - - - Base class method-specific for Electron Backscatter Diffraction (EBSD). - - The general procedure of an EBSD experiment is as follows. - Users load the specimen, collect first a coarse image of the surface. - Next, they set an approximate value for the calibrated working distance and - tilt the stage to set the desired diffraction conditions. - - Users then typically configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration corrector settings and select one or multiple ROIs for - the microscope to machine off automatically. They configure on-the-fly - indexing parameter and start the measurement queue. - - Nowadays, this is in most cases an automated process. The pattern - collection runs during the allocated microscope session until the - queue finishes or gets interrupted by errors or the next user terminates - sessions which run over time. - - Kikuchi pattern surplus eventually multi-modal detector signals are - collected and usually indexed on-the-fly. Patterns may be stored or not - so one should not assume that raw data are always stored. - - Results are stored in files, which afterwards are typically copied - automatically or manual for archival purposes to certain storage - locations or further consumption. The result of such an EBSD - measurement/experiment is a set of usually proprietary or open files - from technology partners. - - This :ref:`NXem_ebsd` base class is a proposal how to represent method-specific - data, metadata, and connections between these for the research field of - electron microscopy. - - More specifically, exemplified here for electron backscatter diffraction (EBSD) - we show how NeXus can be used to solve two key documentation issues so far - missing in the field of EBSD. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to NXem_ebsd) 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 NXem_ebsd make connections to data artifacts which were collected - when working with electron microscopes via the NXem application definition. - Using a file which stores information according to the NXem application definition - has the benefit that it connects the sample, references to the sample processing, - the user operating the microscope, details about the microscope session, - and details about the acquisition and eventual indexing of Kikuchi pattern, - associated overview images, like secondary electron or backscattered electron - images of the region-of-interest probed and many more pieces of information. - - Secondly, NXem_ebsd connects and stores the conventions and reference frames - which were used and which are the key to a correct mathematical interpretation - of every EBSD result. Otherwise, results would be ripped out of their context, - as it is the current situation with many traditional studies where EBSD data - were indexed on-the-fly and shared with the community only via sharing - the strongly processed results file in some technology-partner-specific file - format but without communicating all conventions or relying on the assumptions - that colleagues likely know these conventions even though multiple definitions - are possible. - - NXem_ebsd covers experiments with one-, two-dimensional, and so-called three- - dimensional EBSD datasets. The third dimension is either time (in the case of - quasi in-situ experiments) or space (in the case of serial-sectioning) 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. - - This concept is related to term `Electron Backscatter Diffraction`_ of the EMglossary standard. - - .. _Electron Backscatter Diffraction: https://purls.helmholtz-metadaten.de/emg/EMG_00000019 - - - - - Details about the gnomonic (projection) reference frame. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to label the - base vectors of this coordinate system as Xg, Yg, Zg. - - - - Origin of the gnomonic_projection_reference_frame. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to - assume that this is coordinate Xg = 0, Yg = 0, Zg = 0. - - - - - - - - - Direction of the positively pointing x-axis base vector of the - gnomonic_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing y-axis base vector of the - gnomonic_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing z-axis base vector of the - gnomonic_reference_frame. - - - - - - - - - - - - - - - Details about the definition of the pattern centre as a special point in the gnomonic_reference_frame. - - 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 laying inside the XdYd plane - (of the detector reference frame). - - When the normalization direction is the same as e.g. the detector x-axis direction one - effectively normalizes in fractions of the width of the detector. - - The issue with terms like width and height is that these degenerate if the detector - region-of-interest is square-shaped. This is why instead of referring to width and height - one should report as if one were to measure practically with a ruler and one is specific - about in which direction positive distances are measured. - - For the concepts used to specify the boundary_convention it is assumed that the - region-of-interest is defined by a rectangle, referring to the direction of outer-unit - normals to the respective edges of this rectangle. - - - - From which border of the EBSP (in the detector reference frame) is the pattern - centre's x-position (PCx) measured. - - - - - - - - - - - - In which direction are positive values for the x-axis coordinate value measured - from the specified boundary. - - - - - - - - - - - - From which border of the EBSP (in the detector reference frame) is the pattern - centre's y-position (PCy) measured. - - - - - - - - - - - - In which direction are positive values for the y-axis coordinate value measured - from the specified boundary. - - - - - - - - - - - - - - This group documents relevant details about the conditions and the tools - used for measuring a stack of Kikuchi diffraction pattern with an - electron microscope. - - The most frequently collected EBSD data are captured for rectangular - regions-of-interested which are sampled with regular square or - hexagon-shaped pixels. - - - - 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 need to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes, - 30 minutes, 6 hours, or 24 hours of annealing. - - - - Timestamp relative to which time was counted to aid - converting between time and timestamp. - - - - - - - If available and it is stored in an instance of an application definition this field - specifies the path to an instance of :ref:`NXdata` where the measured patterns - are stored. - - - - - Reference (e.g. path and filename) to an existent data artifact which - stores either the measured pattern or input (already processed EBSD data). - - - - - - This group documents relevant details about the conditions and the tools - used for simulating a stack of Kikuchi diffraction pattern with some - physical model. - - This group should not be confused with a group named simulation that - is however an instance of NXem_sim. Instead, the simulation group here - should be used if (e.g. instead of a measurement) a stack of pattern - were simulated that one wishes to use for indexing patterns. - - In many practical cases where pattern are analyzed on-the-fly and dictionary - indexing strategies are used, so-called master pattern(s) are used to compare - measured or simulated pattern with the master pattern. In this case, - master pattern are the result of a computer simulation and thus should - be stored using an own properly documented entry within a simulation - group as an instance of :ref:`NXem_sim`. - - - - If available and it is stored in an instance of an application definition this field specifies - the path to an instance of :ref:`NXimage_set` where the simulated patterns are stored. - - - - - Reference (e.g. path and filename) to an existent digital resource which - stores either the pattern or input (already processed EBSD data) - which is now processed further as described by this NXem_ebsd instance. - - - - - - 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 indexing results. - - Specifically, the gnomonic projection has to be calibrated. - Typically, silicon or quartz crystals are used for this purpose. - - Considering a system is well-calibrated, it is much more frequently the - case in practice that users assume the system is calibrated (and thus usable) - vs. they perform the calibration of the EBSD system. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software has been calibrated. Consequently, users pick from - an existent library of phase candidates, i.e. - :ref:`NXcrystal_structure` instances. Examples are - reflector models as stored in CRY files (HKL/Channel 5/Flamenco). - - In the second case, users calibrate the system during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Often this person or technician is also in charge of - configuring the graphical user interface and software with which most - users control and perform their analyses. - - For EBSD this has key implications: Taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how the - reference frames are configured and 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' obligation to remember these - settings or write these down in a lab notebook. Otherwise, these metadata - get lost. All these issues are a motivation and problem which - :ref:`NXem_ebsd` solves in that all conventions can be specified explicitly. - - - - If available and it is stored in an instance of an application definition this field specifies - the path to an instance of :ref:`NXem_msr` where calibration is stored. - - - - - Reference to a digital resource where the calibration is stored. - - - - - - Indexing is a data processing step performed either after or while - (on-the-fly) the beam scans the specimen. The resulting method is also - known as orientation imaging microscopy (OIM). - - Different algorithms can be used to index EBSD pattern. Common to them - is the computational step where simulated reference pattern are compared - with measured or simulated patterns. These latter patterns are referred - to via the measurement or simulation groups of this base class. - - Quality descriptors are defined based on which an indexing algorithm - yields a quantitative measure of how similar measured and reference - pattern are, and thus if no, one, or multiple so-called solutions - were found. - - Assumed or simulated pattern are simulated using kinematic or dynamical - theory of electron diffraction delivering master pattern. - - The Hough transform is essentially a discretized Radon transform (for details see `M. van Ginkel et al. <https://www.semanticscholar.org/paper/A-short-introduction-to-the-Radon-and-Hough-and-how-Ginkel/fb6226f606cad489a15e38ed961c419037ccc858>`_). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the interest to use artificial intelligence algorithms. - - - - This group enables to establish a logical connection between previous - processing steps or on-the-fly-performed indexing of the EBSD map. - Typically these processing steps are performed with commercial software. - Therefore, in many cases a results file from this indexing is often - all that is communicated and saved. These are typically files in a format - specific to the instrument and its configuration. - - Typical file formats are CPR/CRC, ANG, OSC, HDF5, H5EBSD, EDAXH5. - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - Binning i.e. downsampling of the pattern. - - - - - Specific parameter relevant only for certain algorithms used. - - - - - Details for each phase used as a model with which the patterns were - indexed. Instances of :ref:`NXcrystal_structure` in this group must - have the group name prefix phase. The identifier in the name is an - integer. We start counting from 1 because the value 0 is reserved for - the special phase that is the null-model, i.e. the null phase, notIndexed. - - - - - 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, mean_angular_deviation, some AI-based - matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be cleaner, also scan_point_positions could be -an instance of NXcg_point_set with a depends_on pointing -to sample_reference_frame ---> - - Calibrated center positions of each scan point - in the sample surface reference system. - - - - - - - - - Fraction of successfully indexed pattern with a phase - not the null-phase vs the number_of_scan_points. - - - - - Number of scan points in the original mapping. - - - - - - An overview of the entire ROI. - - - - Descriptor representing the image contrast. - - - - - - - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the y-axis. - - - - - - - Label for the y axis - - - - - - Calibrated coordinate along the x-axis. - - - - - - - Label for the x axis - - - - - - diff --git a/base_classes/NXem_eds.nxdl.xml b/base_classes/NXem_eds.nxdl.xml deleted file mode 100644 index 6e3d79733..000000000 --- a/base_classes/NXem_eds.nxdl.xml +++ /dev/null @@ -1,225 +0,0 @@ - - - - - - - - - Number of X-ray photon energy (bins) - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Number of IUPAC line names - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDXS). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - X-ray spectroscopy is a surface-sensitive technique. Therefore, three-dimensional elemental - characterzation requires typically a sequence of characterization and preparation of the - surface to expose a new surface layer that can be characterized in the next acquisition. - In effect, the resulting three-dimensional elemental information mappings are truely the - result of a correlation and post-processing of several measurements which is the field - of correlative tomographic usage of electron microscopy. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Accumulated intensity over all pixels of the region-of-interest. - - - - Accumulated counts - - - - - - - Counts - - - - - - Energy axis - - - - - - - Energy - - - - - - - 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. - - - - - - - - - - Comma-separated list of names of elements confirmed in the sample via EDS analysis. - - All members of the list have to be valid chemical_symbols from the periodic table. - - This field can be used when creating instances of NXpeak is not desired. - However, a collection of instances of NXpeak with individual NXion specified - enables also to distinguish isotopic information. - - - - - - - - - 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 :ref:`NXimage_set` instances - and need to be named with the name of the element from the - atom_types field. - - We often observe that signal contributions from several peaks - are summarized and shown together, e.g. the combined signal - under the curve of carbon and oxygen. - - In this case specify the processing details using peaks and weights. - - - - Discouraged free-text field to add additional information. - - - - - Comma-separated list of chemical_symbol-IUPAC X-ray (emission) line name that - documents which elements and their specific lines are theoretically located within - the energy_range of the spectrum from which the EDS (element) map has been computed. - - - - - Associated :math:`[e_{min}, e_{max}]` bounds of the energy - range for which spectrum counts have been accumulated. - - - - - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - A list of weights by how much the intensity of each peak - under peaks was factorized to display the joint intensity - of the image. - - - - - - diff --git a/base_classes/NXem_eels.nxdl.xml b/base_classes/NXem_eels.nxdl.xml deleted file mode 100644 index 4ddef0117..000000000 --- a/base_classes/NXem_eels.nxdl.xml +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - Details about computational stesp how the zero-loss peak was threaded. - - - - The program with which the zero-loss peak correction was performed. - - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each peak in the spectrum considered to be of relevance. - - - - - NXspectrum_set_em specialized for EELS. - - - - diff --git a/base_classes/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml deleted file mode 100644 index 557496537..000000000 --- a/base_classes/NXem_img.nxdl.xml +++ /dev/null @@ -1,61 +0,0 @@ - - - - - - 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? - - - - - - - - - - - - Annulus inner (first value) and outer (second value) half angle. - - - - - - - - diff --git a/base_classes/NXem_msr.nxdl.xml b/base_classes/NXem_msr.nxdl.xml deleted file mode 100644 index d7d590456..000000000 --- a/base_classes/NXem_msr.nxdl.xml +++ /dev/null @@ -1,98 +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 610fe885c..000000000 --- a/base_classes/NXem_sim.nxdl.xml +++ /dev/null @@ -1,59 +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 9277979da..000000000 --- a/base_classes/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,209 +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. - - - - - Mean kinetic energy of the electrons in the energy-dispersive portion of the analyser. - This term should be used for hemispherical analysers. - - This concept is related to term `12.63`_ of the ISO 18115-1:2023 standard. - - .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 - - - - - Kinetic energy set for the dispersive analyzer section. Can be either the set kinetic energy, - or the whole calibrated energy axis of a scan. - - - - - Drift energy for time-of-flight energy dispersive elements. - - - - - 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. - - - - - Diameter of the dispersive orbit - - - - - Radius of the dispersive orbit - - - - - Way of scanning the energy axis - - - - - constant :math:`\Delta E` mode, where the electron retardation (i.e., the fraction of pass energy to - kinetic energy, :math:`R = (E_K - W/E_p)`, is scanned, but the pass energy :math:`E_p` is kept constant. - Here, :math:`W = e \phi` is the spectrometer work function (with the potential difference :math:`\phi_{\mathrm{sample}}` - between the electrochemical potential of electrons in the bulk and the electrostatic potential of an electron in the - vacuum just outside the surface). - - This mode is often used in XPS/UPS because the energy resolution does not change with - changing energy (due to the constant pass energy). - - Synonyms: constant :math:`\Delta E` mode, constant analyser energy mode, CAE - mode, FAT mode - - This concept is related to term `12.64`_ of the ISO 18115-1:2023 standard. - - .. _12.64: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.64 - - - - - constant :math:`\Delta E/E` mode, where the pass energy is scanned such that the electron retardation - ratio is constant. In this mode, electrons of all energies are decelerated with this same - fixed factor. Thus, the pass energy is proportional to the kinetic energy. This mode is often - used in Auger electron spectroscopy (AES) to improve S/N for high-KE electrons, but this - leads to a changing energy resolution (:math:`\Delta E \sim E_p`) at different kinetic energies. - It can however also be used in XPS. - - Synonyms: constant :math:`\Delta E/E` mode, constant retardation ratio mode, CRR - mode, FRR mode - - This concept is related to term `12.66`_ of the ISO 18115-1:2023 standard. - - .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 - - - - - In the fixed energy (FE) mode, the intensity for one single kinetic energy is measured for a - specified time. This mode is particulary useful during setup or alignment of the - electron analyzer, for analysis of stability of the excitation source or for sample - alignment. - - Since the mode measures intensity as a function of time, the difference in channel signals - is not of interest. Therefore, the signals from all channels are summed. - - Synonyms: FE mode - - - - - Snapshot mode does not involve an energy scan and instead collects data from all channels of - the detector without averaging. The resulting spectrum reflects the energy distribution of - particles passing through the analyzer using the current settings. This mode is commonly used - to position the detection energy at the peak of a peak and record the signal, enabling faster - data acquisition within a limited energy range compared to FAT. Snapshot measurements are - particularly suitable for CCD and DLD detectors, which have multiple channels and can accurately - display the peak shape. While five or nine-channel detectors can also be used for snapshot - measurements, their energy resolution is relatively lower. - - - - - In dither acquisition mode, the kinetic energy of the analyzer is randomly varied by a small value - around a central value and at fixed pass energy. This allows reducing or removing inhomogeneities - of the detector efficiency, such as e.g. imposed by a mesh in front of the detector. - Mostly relevant for CCD/DLD type of detectors. - - - - - - - Length of the tof drift electrode - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - - - - Specifies the position of the energy dispesive elemeent 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 energy dispersive element as a component in the instrument. - Conventions from the NXtransformations base class are used. In principle, - the McStas coordinate system is used. The first transformation has to point - either to another component of the system or . (for pointing to the reference frame) - to relate it relative to the experimental setup. Typically, the components of a system - should all be related relative to each other and only one component should relate to - the reference coordinate system. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - diff --git a/base_classes/NXentry.nxdl.xml b/base_classes/NXentry.nxdl.xml old mode 100644 new mode 100755 index 8f8f323ca..7c2950340 --- a/base_classes/NXentry.nxdl.xml +++ b/base_classes/NXentry.nxdl.xml @@ -98,62 +98,32 @@ Extended title for entry - - - Unique identifier for the experiment, - defined by the facility, - possibly linked to the proposals - - + + + Unique identifier for the experiment, + defined by the facility, + possibly linked to the proposals + + Brief summary of the experiment, including key objectives. Description of the full experiment (document in pdf, latex, ...) - - User or Data Acquisition defined group of NeXus files or NXentry - + + User or Data Acquisition defined group of NeXus files or NXentry + Brief summary of the collection, including grouping criteria. - + unique identifier for the measurement, defined by the facility. - - + + UUID identifier for the measurement. Version of UUID used - - - City and country where the experiment took place - - - - Start time of experimental run that includes the current - measurement, for example a beam time. - - - - - End time of experimental run that includes the current - measurement, for example a beam time. - - - - - Name of the institution hosting the facility - - - - - Name of the experimental facility - - - - - Name of the laboratory or beamline - - + Reserved for future use by NIAC. @@ -257,4 +227,4 @@ - \ No newline at end of file + diff --git a/base_classes/NXenvironment.nxdl.xml b/base_classes/NXenvironment.nxdl.xml index 74ed194f0..4f878263b 100644 --- a/base_classes/NXenvironment.nxdl.xml +++ b/base_classes/NXenvironment.nxdl.xml @@ -48,17 +48,6 @@ Note, it is recommended to use NXtransformations instead. - - - This is to be used if there is no actuator/sensor that controls/measures - the environment parameters, but the user would still like to give a value for - it. An example would be a room temperature experiment where the temperature is - not actively measured, but rather estimated. - - Note that this method for recording the environment parameters is not advised, - but using NXsensor and NXactuator is strongly recommended instead. - - NeXus positions components by applying a set of translations and rotations @@ -80,29 +69,6 @@ Additional information, LabView logs, digital photographs, etc - - - Any actuator used to control the environment. This can be linked to an actuator - defined in an NXinstrument instance. - - - - - Any sensor used to monitor the environment. This can be linked to a sensor - defined in an NXinstrument instance. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - + + diff --git a/base_classes/NXevent_data_apm.nxdl.xml b/base_classes/NXevent_data_apm.nxdl.xml deleted file mode 100644 index 6c287de04..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 336d796a7..000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - Base class to store state and (meta)data of events with an electron microscopy. - - Electron microscopes are dynamic. Scientists often report that microscopes - *perform differently* across sessions, that they perform differently from - one day or another. In some cases, root causes for performance differences - are unclear. Users of the instrument may consider such conditions impractical, - or *too poor*, and thus abort their session. Alternatively, users may try to - bring the microscope into a state where conditions are considered better - or of whatever high enough quality for continuing the measurement. - - In all these use cases in practice it would be useful to have a mechanism - whereby time-dependent data of the instrument state can be stored and - documented with an interoperable representation. Indeed, how a session on an - electron microscope is spent depends strongly on the research question, - the user, and the imaging modalities used. - - :ref:`NXevent_data_em` represents an instance to describe and serialize flexibly - whatever is considered a time interval during which the instrument is - considered as stable enough for performing a task with the microscope. - Examples of such tasks are the collecting of data (images and spectra) or - the calibrating of some component of the instrument. Users may wish to take - only a single scan or image and complete their microscope session thereafter. - Alternatively, users are working for much longer time at the microscope, - perform recalibrations in between and take several scans (of different - regions-of-interest of the specimen), or they explore the state of the - microscope for service or maintenance tasks. - - :ref:`NXevent_data_em` serves the harmonization and documentation of this situation - with providing three key sections: Firstly, there is a header section whose - purpose is to contextualize and identify the event instance in time. - Secondly, there is a data and metadata section where individual data collections - can be stored using a standardized representation. - - The idea of the first, the event-based em_lab section, is to document the - state of the microscope as it was during the event. The idea of the other, - the NXem application based em_lab(NXinstrument) section is to keep all those - pieces of information which are static in the sense that they are the same - across multiple :ref:`NXevent_data_em` instance. This reduces the amount of pieces of - information that have to be stored repetitively. - - We are aware of the fact that given the variety how an electron microscope - is used, there is a need for a flexible and adaptive documentation system. - At the same time we are also convinced though that just because one has - different requirements for some specific aspect under the umbrella of settings - to an electron microscope, this does not necessarily warrant that one has to - cook up an own schema. - - Instead, the electron microscopy community should work towards reusing schema - components as frequently as possible. This will enable that there is at all - not only a value of harmonizing electron microscopy research content but also - the technical possibility to build services around such harmonized - pieces of information. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is *stable enough*. Take for instance the acquisition of an image - or a stack of spectra. Having to deal with instabilities is a common theme in - electron microscopy practice. Numerical protocols can be used during data - post-processing to correct for some of the instabilities. - A few exemplar references to provide an overview on the subject 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 and ions, - or detector noise models. This warrants to document the time-dependent - details of individual components of the microscope - as is implemented in :ref:`NXevent_data_em`. - - - - 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. - - - - - Identifier of 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. For which there is at the moment no other place. - - In the long run such free-text field description should be avoided as - they are difficult to machine-interpret. Instead, reference should be given - to refactoring these descriptions into structured metadata. - The reason why in this base class the field event_type is nonetheless kept - is to offer a place whereby practically users may enter data for - follow-up modifications to support arriving at an improved :ref:`NXevent_data_em` base class. - - - - - - - (Meta)data of the dynamics and changes of the microscope during 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 f4901106a..000000000 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ /dev/null @@ -1,49 +0,0 @@ - - - - - - Base class for a set of :ref:`NXevent_data_em` instances. - - Members of the set are instances of :ref:`NXevent_data_em`. These have an associated - time interval during which the conditions 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 experiments with controlled electron - beams in a real microscope or the simulation of such experiments or - individual aspects of such experiments. - - - - - diff --git a/base_classes/NXfabrication.nxdl.xml b/base_classes/NXfabrication.nxdl.xml deleted file mode 100644 index 76f48e3b8..000000000 --- a/base_classes/NXfabrication.nxdl.xml +++ /dev/null @@ -1,70 +0,0 @@ - - - - - - Details about a component as it is defined by its manufacturer. - - - - Company name of the manufacturer. - - - - - Version or model of the component named by the manufacturer. - - - - If different versions exist are possible, the value in this field should be made - specific enough to resolve the version. - - - - - - Ideally, (globally) unique persistent identifier. This may contain e.g. a hash - identifier of the component. - - - - - Serial number of the component. - - - - - Datetime of components initial construction. This refers to the date of - first measurement after new construction or to the relocation date, - if it describes a multicomponent/custom-build setup. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - - - - - Free-text list with eventually multiple terms of - functionalities which the component offers. - - - diff --git a/base_classes/NXfit.nxdl.xml b/base_classes/NXfit.nxdl.xml deleted file mode 100644 index b0d77f2ce..000000000 --- a/base_classes/NXfit.nxdl.xml +++ /dev/null @@ -1,199 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Rank of the dependent and independent data arrays (for - multidimensional/multivariate fit.) - - - - - Description of a fit procedure. - - - - Human-readable label for this fit procedure. - - - - - Input data and results of the fit. - - - - Position values along one or more data dimensions (to hold the - values for the independent variable for this fit procedure). - - - - The ``input_dependent`` field must have the same rank (``dimRank``) - as the ``input_independent`` field. Each individual dimension of ``input_dependent`` - must have the same number of points as the corresponding dimension in - the ``input_independent`` field. - - - - - - Independent input axis for this fit procedure. - - - - The ``input_independent`` field must have the same rank (``dimRank``) - as the ``input_dependent`` field. Each individual dimension of ``input_independent`` - must have the same number of points as the corresponding dimension in - the ``input_dependent`` field. - - - - - - Resulting envelope of applying the `global_fit_function` with its parameter to the data stored - in `input_independent`. - - - - The ``envelope`` field must have the same rank (``dimRank``) - as the ``input_independent`` field. Each individual dimension of ``envelope`` - must have the same number of points as the corresponding dimension in - the ``input_independent`` field. - - - - - - Difference between the envelope and the `input_independent` data to be fitted. - - - - The ``residual`` field must have the same rank (``dimRank``) - as the ``input_independent`` field. Each individual dimension of ``residual`` - must have the same number of points as the corresponding dimension in - the ``input_independent`` field. - - - - - - - One peak of the peak model. - If there is no characteristic name for each peak component, is envisioned that peaks - are labeled as peak_0, peak_1, and so on. - - - - Total area under the curve (can also be used for the total area minus any - background values). - - - - - Relative sensitivity for this peak, to be used for quantification in - an NXprocess. - - As an example, in X-ray spectroscopy could depend on the energy scale - (see position), the ionization cross section, and the element probed. - - - - - Relative area of this peak compared to other peaks. - - The relative area can simply be derived by dividing the total_area by the - total area of all peaks or by a more complicated method (e.g., by - additionally dividing by the relative sensitivity factors). Details shall - be given in `global_fit_function`. - - - - - - One fitted background (functional form, position, and intensities) of the peak fit. - If there is no characteristic name for each peak component, it is envisioned that backgrounds are labeled - as background_0, background_1, and so on. - - - - - Function used to describe the overall fit to the data, taking into account the parameters of the - individual `NXpeak` and `NXfit_background` components. - - - - Oftentimes, if the peaks and fit backgrounds are defined independently (i.e, with their own - parameter sets), the resulting global fit is a function of the form - :math:`model = peak_1(p_1) + peak2(p_2) + backgr(p_3).`, where each :math:`p_x` describes the - set of parameters for one peak/background. - - - - - - Function used to optimize the parameters during peak fitting. - - - - Description of the method used to optimize the parameters during peak fitting. - Examples: - - least squares - - non-linear least squares - - Levenberg-Marquardt algorithm (damped least-squares) - - linear regression - - Bayesian linear regression - - - - - For the optimization, the formula is any optimization process on the `global_fit_function` given above. - As an example, for a linear least squared algorithm on independent components, the formula of the error_function - would be :math:`LLS(peak_1(p_1) + peak2(p_2) + backgr(p_3))`, where each :math:`p_x` describes the set - of parameters for one peak/background. - - It is however also possible to supply more involved formulas (e.g., in the case of constrained fits). - - - - - - Figure-of-merit to determine the goodness of fit, i.e., how well the peak model - fits the measured observations. - - This value (which is a single number) is oftenused to guide adjustments to the - fitting parameters in the peak fitting process. - - - - Metric used to determine the goodness of fit. Examples include: - - :math:`\chi^2`, the squared sum of the sigma-weighted residuals - - reduced :math:`\chi^2`:, :math:`\chi^2`: per degree of freedom - - :math:`R^2`, the coefficient of determination - - - - diff --git a/base_classes/NXfit_background.nxdl.xml b/base_classes/NXfit_background.nxdl.xml deleted file mode 100644 index 5b45fa81e..000000000 --- a/base_classes/NXfit_background.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Rank of the dependent and independent data arrays (for - multidimensional/multivariate fit.) - - - - - Description of the background for an NXfit model. - - - - Human-readable label which specifies which concept/entity - the background represents/identifies. - - - - - - Position values along one or more data dimensions (to hold the - values for the independent variable). - - - - The ``position`` field must have the same rank (``dimRank``) - as the ``intensity`` field. Each individual dimension of ``position`` - must have the same number of points as the corresponding dimension in - the ``intensity`` field. - - - - - - This array holds the intensity/count values of the fitted background - at each position. - - - - The ``intensity`` field must have the same rank (``dimRank``) - as the ``intensity`` field. Each individual dimension of ``position`` - must have the same number of points as the corresponding dimension in - the ``position`` field. - - - - - - - The functional form of the background. - - - diff --git a/base_classes/NXfit_function.nxdl.xml b/base_classes/NXfit_function.nxdl.xml deleted file mode 100644 index d24de7bd9..000000000 --- a/base_classes/NXfit_function.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - This describes a fit function that is used to fit data to any functional form. - - A fit function is used to describe a set of data :math:`y_k, k = 1 ... M`, which are collected as a function - of one or more independent variables :math:`x` at the points :math:`x_k`. The fit function :math:`f` describes - these data in an approximative way as :math:`y_k \approx f(a_0, . . . a_n, x_k)`, - where :math:`a_i, i = 0 . . . n` are the *fit parameters* (which are stored the instances of ``NXfit_parameter``). - - - - Human-readable description of this fit function. - - - - - Mathematical formula of the function, taking into account the instances of ``NXfit_parameter``. - - This should be a python parsable function. Here we should provide which keywords are available - and a BNF of valid grammar. - - - - diff --git a/base_classes/NXhistory.nxdl.xml b/base_classes/NXhistory.nxdl.xml deleted file mode 100644 index 9dfa25d72..000000000 --- a/base_classes/NXhistory.nxdl.xml +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - A set of activities that occurred to a physical entity prior/during experiment. - - Ideally, a full report of the previous operations (or links to a chain of operations). - Alternatively, notes allow for additional descriptors in any format. - - - - Any activity that was performed on the physical entity prior or during the experiment. In - the future, if there is base class inheritance, this can describe any activity, - including processes and measurements. - - - - - - Any physical process that was performed on the physical entity prior or during the - experiment. - - - - - Any chemical process that was performed on the physical entity prior or during the - experiment. - - - - - An ID or reference to the location or a unique (globally - persistent) identifier of e.g. another file which gives - as many as possible details of the history event. - - - - - - A descriptor to keep track of the treatment of the physical entity before or during the - experiment (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - This should only be used in case that there is no rigorous description - using the base classes above. This field can also be used to pull in any activities - that are not well described by an existing base class definition. - - - diff --git a/base_classes/NXimage_set.nxdl.xml b/base_classes/NXimage_set.nxdl.xml deleted file mode 100644 index 9106ef84f..000000000 --- a/base_classes/NXimage_set.nxdl.xml +++ /dev/null @@ -1,652 +0,0 @@ - - - - - - - - - - Number of images in the stack, for stacks the slowest dimension. - - - - - Number of image points along the slow dimension (k equivalent to z). - - - - - Number of image points along the fast dimension (j equivalent to y). - - - - - Number of image points along the fastest dimension (i equivalent to x). - - - - - Base class for reporting a set of images. - - The mostly commonly used scanning methods are supported. That is one-, - two-, three-dimensional ROIs discretized using regular Euclidean tilings. - - Colloquially, an image is understood as a discretized representation of intensity distribution - that was detected or simulated for some ROI. When discretized with regular Euclidean tilings - the terms pixel and voxel identify the smallest discretization unit. Pixel and voxel are polygonal - or polyhedral unit cells respectively of the underlying tiling of the ROI within the reference space. - For all other tilings e.g. non-equispaced, the shape and size of pixel and voxel differs. Using the term - (image) point is eventually is more appropriate for such tilings. Therefore, all docstrings in this base class - refer to points (including pixel and voxel i.e. regular tilings). - - Point coordinates identify the location of the barycentre. - - For images in reciprocal space in practice, complex numbers are encoded via some - formatted pair of real values. Typically, fast algorithms for computing Fourier transformations - (FFT) are used to encode images in reciprocal (frequency) space. FFT libraries are used - for implementing the key functionalities of these mathematical operations. - - Different libraries use different representations and encoding of the images. - Details can be found in the respective sections of the typical FFT libraries documentations - - * `FFTW by M. Frigo and S. G. Johnson <https://www.fftw.org/fftw3_doc/Tutorial.html#Tutorial>`_ - * `Intel MKL by the Intel Co. <https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2024-2/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - * `NFFT by the Chemnitz group <https://www-user.tu-chemnitz.de/~potts/nfft/>`_ for non-equispaced computations - - Users are strongly advised to inspect carefully which specific conventions their library uses - to enable storing and modifying the implementation of their code such that the serialized - representations as they are detailed here for NeXus match. - - It is often the case that several images are combined using processing. In this case, - the number of images which are combined in a collection is not necessarily the same - for each collection. The NXimage_set base class addresses this logical distinction - through the notation of image_identifier and group_identifier concepts. - That is image_identifier are always counting from offset in increments of one. - as each image is its own entity. By contrast, a group may contain no, or several images. - Consequently, group_identifier are not required to be contiguous. - - - - Details how NXdata instance were processed from detector readings/raw data. - - - - Resolvable data artifact (e.g. file) from which all values in the :ref:`NXdata` - instances in this :ref:`NXimage_set` were loaded during parsing. - - Possibility to document from which specific other serialized resource as the source - pieces of information were processed when using NeXus as a semantic file format - to serialize that information differently. - - The group in combination with an added field *absolute_path* therein adds context. - - - - Reference to a location inside the artifact that points to the specific group of values - that were processed if the artifacts contains several groups of values and thus - further resolving of ambiguities is required. - - - - - - - Link or name of an :ref:`NXdetector` instance with which the data were - collected. - - - - - Program used for processing. - - - - - - - One-dimensional image. - - - - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - - - - - - - - Real part of the image intensity per point. - - - - - - - - Imaginary part of the image intensity per point. - - - - - - - - Image intensity as a complex number as an alternative to real and - imaginary fields if values are stored as interleaved complex numbers. - - - - - - - - Point coordinate along the fastest dimension. - - - - - - - Point coordinate along the fastest dimension. - - - - - - - Two-dimensional image. - - - - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - - - - - - - - - Real part of the image intensity per point. - - - - - - - - - Imaginary part of the image intensity per point. - - - - - - - - - Image intensity as a complex number as an alternative to real and - imaginary fields if values are stored as interleaved complex numbers. - - - - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension. - - - - - - Point coordinate along the fastest dimension. - - - - - - - Point coordinate along the fastest dimension. - - - - - - - Three-dimensional image. - - - - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - - - - - - - - - - Real part of the image intensity per point. - - - - - - - - - - Imaginary part of the image intensity per point. - - - - - - - - - - Image intensity as a complex number as an alternative to real and - imaginary fields if values are stored as interleaved complex numbers. - - - - - - - - - - Point coordinate along the slow dimension. - - - - - - - Point coordinate along the slow dimension. - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension. - - - - - - Point coordinate along the fastest dimension. - - - - - - - Point coordinate along the fastest dimension. - - - - - - - Collection of image_1d. - - - - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - - - - - - - - - Real part of the image intensity per point. - - - - - - - - - Imaginary part of the image intensity per point. - - - - - - - - - Image intensity as a complex number as an alternative to real and - imaginary fields if values are stored as interleaved complex numbers. - - - - - - - - - Group identifier - - - - - - - Group identifier - - - - - - Image identifier - - - - - - - Image identifier - - - - - - Point coordinate along the fastest dimension. - - - - - - - Point coordinate along the fastest dimension. - - - - - - - Collection of two-dimensional images. - - - - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - - - - - - - - - - Real part of the image intensity per point. - - - - - - - - - - Imaginary part of the image intensity per point. - - - - - - - - - - Image intensity as a complex number as an alternative to real and - imaginary fields if values are stored as interleaved complex numbers. - - - - - - - - - - Group identifier - - - - - - - Group identifier - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension. - - - - - - Point coordinate along the fastest dimension. - - - - - - - Point coordinate along the fastest dimension. - - - - - - - Collection of three-dimensional images. - - - - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - - - - - - - - - - - Real part of the image intensity per point. - - - - - - - - - - - Imaginary part of the image intensity per point. - - - - - - - - - - - Image intensity as a complex number as an alternative to real and - imaginary fields if values are stored as interleaved complex numbers. - - - - - - - - - - - Group identifier - - - - - - - Group identifier - - - - - - Image identifier - - - - - - - Image identifier - - - - - - Point coordinate along the slow dimension. - - - - - - - Point coordinate along the slow dimension. - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension. - - - - - - Point coordinate along the fastest dimension. - - - - - - - Point coordinate along the fastest dimension. - - - - - diff --git a/base_classes/NXinstrument.nxdl.xml b/base_classes/NXinstrument.nxdl.xml index 197163ff3..15e764540 100644 --- a/base_classes/NXinstrument.nxdl.xml +++ b/base_classes/NXinstrument.nxdl.xml @@ -42,7 +42,6 @@ short name for instrument, perhaps the acronym - @@ -56,20 +55,16 @@ - - - - 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 ee278ead9..000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,158 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Base class for documenting the set of atoms of a (molecular) ion. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. - - The identifier zero is reserved for the special unknown ion type. - - - - - Vector of nuclide hash values. - - Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` - encode the number of protons :math:`Z` and the number of neutrons :math:`N` - of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. - - The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. - The first column specifies the nuclide mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no - isotope-specific information about the element encoded is relevant. - The second row specifies the number of protons :math:`Z` or 0. - The value 0 in this case documents a placeholder or that no element-specific - information is relevant. - Taking a carbon-14 nuclide as an example the mass number is 14. - That is encoded as a value pair (14, 6) as one row of the table. - - Therefore, this notation is the typical superscribed nuclide mass number - and subscripted number of protons element notation e.g. :math:`^{14}C`. - The array is stored matching the order of nuclide_hash. - - - - - - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored alongside ranging - definitions. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - In the example of atom probe microscopy, only positive values will be measured - as the ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, the value should - be set to zero. - - In atom probe microscopy this is for example the case when using - classical ranging definition files in formats like RNG, RRNG. - These file formats do not document the charge state explicitly - but the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - Details on ranging definition files can be found in the literature: - `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of UTF-8 characters, ideally using LaTeX - notation to specify the isotopes, ions, and charge state. - Examples are 12C + or Al +++. - - To ease automated parsing, isotope_vector should be the - preferred machine-readable information used. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of the - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries inclusive). This field is primarily of interest - for documenting :ref:`NXprocess` steps of indexing a - ToF/mass-to-charge state histogram. - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index e878d25e3..000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,96 +0,0 @@ - - - - - - - - Base class for an electro-magnetic lens or a compound lens. - - For :ref:`NXtransformations` the origin of the coordinate system is placed - in the center of the lens (its polepiece, pinhole, or another - point of reference). The origin should be specified in the :ref:`NXtransformations`. - - For details of electro-magnetic lenses in the literature - see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - - Descriptor for the lens excitation when the exact technical details - are unknown or not directly controllable as the control software of - the microscope does not enable or was not configured to display these - values (for end users). - - Although this value does not document the exact physical voltage or - excitation, it can still give useful context to reproduce the lens - setting, provided a properly working instrument and software sets the lens - into a similar state to the technical level possible when no more - information is available physically or accessible legally. - - - - - Descriptor for the operation mode of the lens when other details are not - directly controllable as the control software of the microscope - does not enable or is not configured to display these values. - - Like value, the mode can only be interpreted for a specific microscope - but can still be useful to guide users as to how to repeat the measurement. - - - - - - Excitation voltage of the lens. - - For dipoles it is a single number. - For higher order multipoles, it is an array. - - - - - Excitation current of the lens. - - For dipoles it is a single number. - For higher-order multipoles, it is an array. - - - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - diff --git a/base_classes/NXmanipulator.nxdl.xml b/base_classes/NXmanipulator.nxdl.xml deleted file mode 100644 index a057a167d..000000000 --- a/base_classes/NXmanipulator.nxdl.xml +++ /dev/null @@ -1,257 +0,0 @@ - - - - - - Extension of NXpositioner to include fields to describe the use of manipulators - in photoemission experiments. - - - - Name of the manipulator. - - - - - A description of the manipulator. - - - - - Type of manipulator, Hexapod, Rod, etc. - - - - - Cryostat for cooling the sample. - - - - - - - - - - In case of a fixed or averaged cooling temperature, this is the scalar temperature setpoint. - It can also be a 1D array of temperature setpoints (without time stamps). - - - - - - In the case of an experiment in which the temperature is changed and the setpoints are - recorded with time stamps, this is an array of length m of temperature setpoints. - - - - - - - - Temperature sensor measuring the sample temperature. - - - - - - - - - In case of a single or averaged temperature measurement, this is the scalar temperature measured - by the sample temperature sensor. It can also be a 1D array of measured temperatures - (without time stamps). - - - - - - In the case of an experiment in which the temperature changes and is recorded with time stamps, - this is an array of length m of temperatures. - - - - - - - Device to heat the sample. - - - - - - - - - In case of a fixed or averaged heating power, this is the scalar heater power. - It can also be a 1D array of heater powers (without time stamps). - - - - - - In the case of an experiment in which the heater power is changed and recorded with time stamps, - this is an array of length m of temperature setpoints. - - - - - - - In case of a fixed or averaged temperature, this is the scalar temperature setpoint. - It can also be a 1D array of temperature setpoints (without time stamps). - - - - - - In the case of an experiment in which the temperature is changed and the setpoints are - recorded with time stamps, this is an array of length m of temperature setpoints. - - - - - - - - Amperemeter measuring the drain current of the sample and sample holder. - - - - - - - - - In case of a single or averaged drain current measurement, this is the scalar drain current measured between - the sample and sample holder. It can also be an 1D array of measured currents (without time stamps). - - - - - - In the case of an experiment in which the current changes and is recorded with - time stamps, this is an array of length m of currents. - - - - - - - Actuator applying a voltage to sample and sample holder. - - - - - - - - - - In case of a fixed or averaged applied bias, this is the scalar voltage applied between - sample and sample holder. It can also be an 1D array of voltage setpoints (without time stamps). - - - - - - In the case of an experiment in which the bias is changed and the setpoints are - recorded with time stamps, this is an array of length m of voltage setpoints. - - - - - - - - Sensor measuring the voltage applied to sample and sample holder. - - - - - - - - - In case of a single or averaged bias measurement, this is the scalar voltage measured between - sample and sample holder. It can also be an 1D array of measured voltages (without time stamps). - - - - - - In the case of an experiment in which the bias changes and is recorded with - time stamps, this is an array of length m of voltages. - - - - - - - Any additional actuator on the manipulator used to control an external - condition. - - - - - Any additional sensors on the manipulator used to monitor an external condition. - - - - - Class to describe the motors that are used in the manipulator - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the manipulator as a component in the instrument. Conventions from - the NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - diff --git a/base_classes/NXmonochromator.nxdl.xml b/base_classes/NXmonochromator.nxdl.xml index dd96e3a26..50a83cd93 100644 --- a/base_classes/NXmonochromator.nxdl.xml +++ b/base_classes/NXmonochromator.nxdl.xml @@ -60,26 +60,6 @@ energy standard deviation - - - Energy dispersion at the exit slit, typically given as eV/mm. - - - - - Wavelength dispersion at the exit slit. - - - - - Size, position and shape of the entrance slit of the monochromator. - - - - - Size, position and shape of the exit slit of the monochromator. - - @@ -125,3 +105,4 @@ + diff --git a/base_classes/NXopt_window.nxdl.xml b/base_classes/NXopt_window.nxdl.xml deleted file mode 100644 index f1fc90e67..000000000 --- a/base_classes/NXopt_window.nxdl.xml +++ /dev/null @@ -1,128 +0,0 @@ - - - - - - - A window of a cryostat, heater, vacuum chamber or a simple glass slide. - - This first verion originates from NXopt to describe cryostate windows - and possible influences for ellipsometry measurements. - - For environmental measurements, the environment (liquid, vapor - etc.) is enclosed in a cell, which has windows both in the - direction of the source (entry window) and the detector (exit - window) (looking from the sample). In case that the entry and exit - windows are not the same type and do not have the same properties, - use a second 'WINDOW(NXaperture)' field. - - The windows also add a phase shift to the light altering the - measured signal. This shift has to be corrected based on measuring - a known sample (reference sample) or the actual sample of interest - in the environmental cell. State if a window correction has been - performed in 'window_effects_corrected'. Reference data should be - considered as a separate experiment, and a link to the NeXus file - should be added in reference_data_link in measured_data. - - The window is considered to be a part of the sample stage but also - beam path. Hence, its position within the beam path should be - defined by the 'depends_on' field. - - - - - Was a window correction performed? If 'True' describe the window - correction procedure in 'window_correction/procedure'. - - - - - Type of effects due to this window on the measurement. - - - - - - - - - - - Was a window correction performed? If 'True' describe the - window correction procedure in '' - - - - Describe when (before or after the main measurement + time - stamp in 'date') and how the window effects have been - corrected, i.e. either mathematically or by performing a - reference measurement. In the latter case, provide the link to - to the reference data in 'reference_data_link'. - - - - - Link to the NeXus file which describes the reference data if a - reference measurement for window correction was performed. - Ideally, the reference measurement was performed on a reference - sample and on the same sample, and using the same conditions as - for the actual measurement with and without windows. It should - have been conducted as close in time to the actual measurement - as possible. - - - - - - The material of the window. - - - - - - - - - - - - - - - If you specified 'other' as material, decsribe here what it is. - - - - - Thickness of the window. - - - - - Angle of the window normal (outer) vs. the substrate normal - (similar to the angle of incidence). - - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index b0546c8c7..000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,155 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Distance which is present between the specimen surface and the detector plane. - - This concept is related to term `Camera Length`_ of the EMglossary standard. - - .. _Camera Length: https://purls.helmholtz-metadaten.de/emg/EMG_00000008 - - - - - The factor of enlargement of the apparent size, - not the physical size, of an object. - - - - - The defocus aberration constant (oftentimes referred to as C_1_0). - See respective details in :ref:`NXaberration` class instances. - - - - - The angle which is given by the semi-opening angle of the cone in a convergent - beam. - - This concept is related to term `Convergence Angle`_ of the EMglossary standard. - - .. _Convergence Angle: https://purls.helmholtz-metadaten.de/emg/EMG_00000010 - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Distance which is determined along the optical axis within the column from (1) the - lower end of the final optical element between the source and the specimen stage; - to (2) the point where the beam is focused. - - This concept is related to term `Working Distance`_ of the EMglossary standard. - - .. _Working Distance: https://purls.helmholtz-metadaten.de/emg/EMG_00000050 - - - - - - Geometry of the cross-section formed when the primary beam shines onto the - specimen surface. - - - - - Electrical current which arrives at the specimen. - - This concept is related to term `Probe Current`_ of the EMglossary standard. - - .. _Probe Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000041 - - - - - - - Specify further details how incipient electron or ion dose was quantified (using - beam_current, probe_current). - - - - - - Details about an imaging setting used during acquisition to correct perspective - distortion when imaging a tilted surface or cross section. - - This concept is related to term `Tilt Correction`_ of the EMglossary standard. - - .. _Tilt Correction: https://purls.helmholtz-metadaten.de/emg/EMG_00000047 - - - - - Details about a dynamic focus correction used. - - This concept is related to term `Dynamic Focus Correction`_ of the EMglossary standard. - - .. _Dynamic Focus Correction: https://purls.helmholtz-metadaten.de/emg/EMG_00000016 - - - - - Details about a workflow used to keep the specimen in focus by automatic means. - - This concept is related to term `Dynamic Refocusing`_ of the EMglossary standard. - - .. _Dynamic Refocusing: https://purls.helmholtz-metadaten.de/emg/EMG_00000017 - - - - - Distance which lies between the principal plane of the lens and the focal point - along the optical axis. - - This concept is related to term `Focal Length`_ of the EMglossary standard. - - .. _Focal Length: https://purls.helmholtz-metadaten.de/emg/EMG_00000029 - - - diff --git a/base_classes/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml deleted file mode 100644 index 86809edda..000000000 --- a/base_classes/NXpeak.nxdl.xml +++ /dev/null @@ -1,86 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Rank of the dependent and independent data arrays (for - multidimensional/multivariate fit.) - - - - - Base class for describing a peak, its functional form, and support values - (i.e., the discretization (points) at which the function has been evaluated). - - - - Human-readable label which specifies which concept/entity - the peak represents/identifies. - - - - - - Position values along one or more data dimensions (to hold the - values for the independent variable). - - - - The ``position`` field must have the same rank (``dimRank``) - as the ``intensity`` field. Each individual dimension of ``position`` - must have the same number of points as the corresponding dimension in - the ``intensity`` field. - - - - - - This array holds the intensity/count values of the fitted peak at each position. - - - - The ``intensity`` field must have the same rank (``dimRank``) - as the ``intensity`` field. Each individual dimension of ``position`` - must have the same number of points as the corresponding dimension in - the ``position`` field. - - - - - - - The functional form of the peak. This could be a Gaussian, Lorentzian, - Voigt, etc. - - - - - Total area under the curve. - - - diff --git a/base_classes/NXphysical_process.nxdl.xml b/base_classes/NXphysical_process.nxdl.xml deleted file mode 100644 index d422e516c..000000000 --- a/base_classes/NXphysical_process.nxdl.xml +++ /dev/null @@ -1,61 +0,0 @@ - - - - - - A planned or unplanned process which results in physical changes in a specified material. - - A physical change involve changes only in intermolecular forces, not in the chemical bonds. - Examples include sample preparation, material transformation, or (partially) destructive measurements. - - - - ISO 8601 formatted time code (with local time zone offset to UTC information - included) when this process started. - - - - - ISO 8601 formatted time code (with local time zone offset to UTC information - included) when this process ended. - - - - - Short description of the activity. - - - - - Method by which this process was performed. - - - - - This can be any data or other descriptor acquired during the physical process - (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - diff --git a/base_classes/NXprocess.nxdl.xml b/base_classes/NXprocess.nxdl.xml index 7a9cecd4d..d7d1a80f8 100644 --- a/base_classes/NXprocess.nxdl.xml +++ b/base_classes/NXprocess.nxdl.xml @@ -43,21 +43,6 @@ Date and time of processing. - - - Describes the operations of image registration - - - - - Describes the operations of image distortion correction - - - - - Describes the operations of calibration procedures, e.g. axis calibrations. - - The note will contain information about how the data was processed @@ -82,3 +67,4 @@ + diff --git a/base_classes/NXprocess_mpes.nxdl.xml b/base_classes/NXprocess_mpes.nxdl.xml deleted file mode 100644 index 337d040f9..000000000 --- a/base_classes/NXprocess_mpes.nxdl.xml +++ /dev/null @@ -1,317 +0,0 @@ - - - - - - :ref:`NXprocess_mpes` describes events of data processing, reconstruction, - or analysis for photoemission-related data. - - It extends the NXprocess class and provides a glossary of explicitly named processes - and their metadata which are typical for photoemission data. - - For now, the extension of NXprocess is performed by simply copying all existing groups, fields, - and attibute from NXprocess. In the future, it is envisioned that this extension can be solved by - base class inheritance. - - - - Name of the program used - - - - - Sequence index of processing, - for determining the order of multiple **NXprocess** steps. - Starts with 1. - - - - - Version of the program used - - - - - Date and time of processing. - - - - - Calibration event on the energy axis. - - For XPS, the calibration should ideally be performed according to - `ISO 15472:2010`_ specification. - - .. _ISO 15472:2010: https://www.iso.org/standard/74811.html - - - - - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - Calibration event on a k-space axis. - - It is envisioned that the individual calibrations for each coordinate are - stored as kx_calibration, ky_calibration, kz_calibration, in accordance - with the axis name definitions in NXdata_mpes. - - It is also possible to have k_parallel_calibration and k_perp_calibration if - the momentum axes are defined as k_parallel and k_perp for the parallel and - perpendicular momenta, respectively. - - - - - - - - - This is the calibrated k-space axis to be used for data plotting. - - - - - - Calibration event of an angular axis. - - It is envisioned that the individual calibrations for each angle are - stored as angular0_calibration, angular1_calibration, etc., in accordance - with the axis name definitions in NXdata_mpes. - - - - - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - Calibration event of a spatial axis. - - It is envisioned that the individual calibrations for each angle are - stored as spatial0_calibration, spatial1_calibration, etc., in accordance - with the axis name definitions in NXdata_mpes. - - - - - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - Calibration event of the delay time. - - - - - - - - - This is the calibrated delay time axis to be used for data plotting. - - - - - - Calibration event of the beam polarization angle. - - - - - - - - - This is the calibrated polarization angle axis to be used for data plotting. - - - - - - Calibration event of the ellipticity of the incoming or outgoing beam. - - - - - - - - - This is the calibrated ellipticity axis to be used for data plotting. - - - - - - For energy referencing, the measured energies are corrected for the charging potential - (i.e., the electrical potential of the surface region of an insulating sample, caused by - irradiation) such that those energies correspond to a sample with no surface charge. - Usually, the energy axis is adjusted by shifting all energies uniformally until one - well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. - - This concept is related to term `12.74 ff.`_ of the ISO 18115-1:2023 standard. - - .. _12.74 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 - - - - - - - - - Electronic core or valence level that was used for the calibration. - - - - - Reference peak that was used for the calibration. - - For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge | vacuum level - - - - - The binding energy (in units of eV) that the specified emission line appeared at, - after adjusting the binding energy scale. - - This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. - - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - Offset between measured binding energy and calibrated binding energy of the - emission line. - - - - - This is the calibrated energy axis to be used for data plotting. - - This should link to /entry/data/energy. - - - - - - In the transmission correction, each intensity measurement for electrons of a given - kinetic energy is multiplied by the corresponding value in the relative_intensity - field of the transmission_function. This calibration procedure is used to account for - the different tranmsission efficiencies when using different lens modes. - - - - Transmission function of the electron analyser. - - The transmission function (TF) specifies the detection efficiency for electrons of - different kinetic energy passing through the electron analyser. - This can be a link to /entry/instrument/electronanalyser/transmission_function. - - - - - - - - - - - - - - Kinetic energy values - - - - - - - - Relative transmission efficiency for the given kinetic energies - - - - - - - - - - Describes the operations of image registration - - - - - Describes the operations of image distortion correction - - - - - Describes the operations of calibration procedures, e.g. axis calibrations. - - - - - The note will contain information about how the data was processed - or anything about the data provenance. - The contents of the note can be anything that the processing code - can understand, or simple text. - - The name will be numbered to allow for ordering of steps. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - - - diff --git a/base_classes/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/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/NXresolution.nxdl.xml b/base_classes/NXresolution.nxdl.xml deleted file mode 100644 index 4197d5550..000000000 --- a/base_classes/NXresolution.nxdl.xml +++ /dev/null @@ -1,125 +0,0 @@ - - - - - - Describes the resolution of a physical quantity. - - - - The physical quantity of the resolution, e.g., - energy, momentum, time, etc. - - - - - The process by which the resolution was determined. - - - - - - - - - - - Additional details of the estimate or description of the calibration procedure - - - - - The resolution of the physical quantity. - - - - - Standard deviation of the resolution of the physical quantity. - - - - - Ratio of the resolution at a specified measurand value to that measurand value, - - - - - Standard deviation of the relative resolution of the physical quantity. - - - - - The response of the instrument or part to a infinitesimally sharp input signal - along the physical quantity of this group. - This is also sometimes called instrument response function for time resolution or - point spread function for spatial response. - The resolution is typically determined by taking the full width at half maximum (FWHM) - of the response function. - - - - The input axis or grid of the response function. - The unit should match the one of the resolution field. - - - - - The magnitude of the response function corresponding to the points - in the input axis or grid. - This field should have the same dimensions as `input`. - - - - - - A symbol linking to another path in this appdef to be referred to from the - `resolution_formula` field. This should be a valid path inside this application - definition, i.e., of the form /entry/instrument/my_part/my_field. - - - - - A resolution formula to determine the resolution from a set of symbols as - entered by the `formula_...` fields. - The output unit should match the provided unit of this field. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - - For storing details and data of a calibration to derive a resolution from data. - - - diff --git a/base_classes/NXroot.nxdl.xml b/base_classes/NXroot.nxdl.xml index 18bca6113..de58feba5 100644 --- a/base_classes/NXroot.nxdl.xml +++ b/base_classes/NXroot.nxdl.xml @@ -46,39 +46,15 @@ Date and time of last file change at close - - - A repository containing the application definitions - used for creating this file. - If the NeXus_version attribute contains a commit distance and hash - this should refer to this repository. - - - Version of NeXus definitions used in writing the file. - This may either be a date based version tag of the form `vYYYY.MM` - or a version tag with a commit distance and source control (e.g., git) hash of - the form `vYYYY.MM.post1.dev<commit-distance>.g<git-hash>`. - It may contain an additional `.dYYYYMMDD` timestamp appendix - for dirty repositories. - If the version contains a commit distance and hash the - NeXus_repository attribute should be written with the - repository url containing this version. + Version of NeXus API used in writing the file. - Only used when the NAPI or pynxtools has written the file. + Only used when the NAPI has written the file. Note that this is different from the version of the base class or application definition version number. - - - A list of concepts in an application definition this file describes. - This is for partially filling an application definition. - If this attribute is not present the application definition is assumed - to be valid, if not only the specified concepts/paths are assumed to be valid. - - Version of HDF (version 4) library used in writing the file @@ -125,4 +101,5 @@ for a summary of the discussion. - \ No newline at end of file + + diff --git a/base_classes/NXrotation_set.nxdl.xml b/base_classes/NXrotation_set.nxdl.xml deleted file mode 100644 index 3f47e3fb8..000000000 --- a/base_classes/NXrotation_set.nxdl.xml +++ /dev/null @@ -1,256 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of value tuples. - - - - - How many phases with usually different crystal and symmetry are distinguished. - - - - - Base class to detail a set of rotations, orientations, and disorientations. - - For getting a more detailed insight into the discussion of the - parameterized description of orientations in materials science see: - - * `H.-J. Bunge <https://doi.org/10.1016/C2013-0-11769-2>`_ - * `T. B. Britton et al. <https://doi.org/10.1016/j.matchar.2016.04.008>`_ - * `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_ - * `A. Morawiec <https://doi.org/10.1007/978-3-662-09156-2>`_ - - Once orientations are defined, one can continue to characterize the - misorientation and specifically the disorientation. The misorientation describes - the rotation that is required to register the lattices of two oriented objects - (like crystal lattice) into a crystallographic equivalent orientation: - - * `R. Bonnet <https://doi.org/10.1107/S0567739480000186>`_ - - - - Reference to an instance of :ref:`NXcoordinate_system_set` which contextualizes - how the here reported parameterized quantities can be interpreted. - - - - - - Point group which defines the symmetry of the crystal. - - This has to be at least a single string. If crystal_symmetry is not - provided point group 1 is assumed. - - In the case that misorientation or disorientation fields are used - and the two crystal sets resolve for phases with a different - crystal symmetry, this field has to encode two string. - In this case the first string is for phase A the second one for phase B. - An example of this most complex case is the description of the - disorientation between crystals adjoining a hetero-phase boundary. - - - - - - - - Point group which defines an assumed symmetry imprinted upon processing - the material/sample which could give rise to or may justify to use a - simplified description of rotations, orientations, misorientations, - and disorientations via numerical procedures that are known as - symmetrization. - - If sample_symmetry is not provided point group 1 is assumed. - - The traditionally used symmetrization operations within the texture - community in Materials Science, though, are thanks to methodology and - software improvements no longer strictly needed. Therefore, users are - encouraged to set the sample_symmetry to 1 (triclinic) and thus assume - there is no justification to assume the imprinting of additional - symmetry because of the processing. - - In practice one often faces situations where indeed these assumed - symmetries are anyway not fully observed, and thus an accepting of - eventual inaccuracies just for the sake of reporting a simplified - symmetrized description should be avoided. - - - - - - - - The set of rotations expressed in quaternion parameterization considering - crystal_symmetry and sample_symmetry. Rotations which should be - interpreted as antipodal are not marked as such. - - - - - - - - - The set of rotations expressed in Euler angle parameterization considering - the same applied symmetries as detailed for the field rotation_quaternion. - To interpret Euler angles correctly, it is necessary to inspect the - conventions behind depends_on to resolve which of the many Euler-angle - conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - - - - - - - - - - - True for all those value tuples which have assumed antipodal symmetry. - False for all others. - - - - - - - - The set of orientations expressed in quaternion parameterization and - obeying symmetry for equivalent cases as detailed in crystal_symmetry - and sample_symmetry. The supplementary field is_antipodal can be used - to mark orientations with the antipodal property. - - - - - - - - - The set of orientations expressed in Euler angle parameterization following - the same assumptions like for orientation_quaternion. - To interpret Euler angles correctly, it is necessary to inspect the - conventions behind depends_on to resolve which of the many Euler-angle - conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - - - - - - - - - - - The set of misorientations expressed in quaternion parameterization - obeying symmetry operations for equivalent misorientations - as defined by crystal_symmetry and sample_symmetry. - - - - - - - - - Misorientation angular argument (eventually signed) following the same - symmetry assumptions as expressed for the field misorientation_quaternion. - - - - - - - - Misorientation axis (normalized) and signed following the same - symmetry assumptions as expressed for the field misorientation_angle. - - - - - - - - - - The set of disorientation expressed in quaternion parameterization - obeying symmetry operations for equivalent misorientations - as defined by crystal_symmetry and sample_symmetry. - - - - - - - - - Disorientation angular argument (should not be signed, see - `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_) - following the same symmetry assumptions as expressed for the field - disorientation_quaternion. - - - - - - - - Disorientation axis (normalized) following the same symmetry assumptions - as expressed for the field disorientation_angle. - - - - - - - - diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml old mode 100644 new mode 100755 index 4b15f3b8f..c101fcb56 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -48,9 +48,6 @@ Descriptive name of sample - - Identification number or signatures of the sample used. - The chemical formula specified using CIF conventions. @@ -382,63 +379,13 @@ - Any positioner (motor, PZT, ...) used to locate the sample - - - - This group describes the shape of the sample - - - - - Physical form of the sample material. - Examples include single crystal, foil, pellet, powder, thin film, disc, foam, gas, liquid, amorphous. - - - - - If the sample is a single crystal, add description of single crystal and unit - cell. - - - - - Set of sample components and their configuration. - There can only be one NXsample_component_set in one component. - - - - - - If the sample is made from a pure substance and cannot be further divided using - NXsample_component. - - - - - - Details about the sample vendor (company or research group) - - - - - An (ideally) globally unique identifier for the sample. - - - - - - Any environmental or external stimuli/measurements. - These can include, among others: - applied pressure, surrounding gas phase and gas pressure, - external electric/magnetic/mechanical fields, temperature, ... - - - - - A set of physical processes that occurred to the sample prior/during experiment. - - + Any positioner (motor, PZT, ...) used to locate the sample + + + + This group describes the shape of the sample + + .. index:: plotting @@ -471,3 +418,4 @@ + diff --git a/base_classes/NXsample_component.nxdl.xml b/base_classes/NXsample_component.nxdl.xml index 3c4670a14..1b5a28261 100644 --- a/base_classes/NXsample_component.nxdl.xml +++ b/base_classes/NXsample_component.nxdl.xml @@ -38,16 +38,11 @@ - One group like this per component can be recorded for a sample consisting of multiple components. + One group like this per component can be recorded For a sample consisting of multiple components. Descriptive name of sample component - - - Identification number or signatures of the sample component used. - - The chemical formula specified using CIF conventions. @@ -144,48 +139,6 @@ As a function of Wavelength - - - If the component is a single crystal, add description of single crystal and unit - cell. - - - - - Set of sub-components and their configuration. - There can only be one NXsample_component_set in one component. - - - - - - If the component is made from a pure substance and cannot be further divided - using NXsample_component. - - - - - - Details about the sample component vendor (company or research group) - - - - - An (ideally) globally unique identifier for the sample component. - - - - - A set of physical processes that occurred to the sample component prior/during - experiment. - - - - - Any NXsample_component depends on the instance of NXsample_component_set, at the same level of - description granularity where the component is located. - - .. index:: plotting @@ -199,4 +152,4 @@ for a summary of the discussion. - \ No newline at end of file + diff --git a/base_classes/NXsample_component_set.nxdl.xml b/base_classes/NXsample_component_set.nxdl.xml deleted file mode 100644 index aa3a0e794..000000000 --- a/base_classes/NXsample_component_set.nxdl.xml +++ /dev/null @@ -1,78 +0,0 @@ - - - - - - - - number of components - - - - - Set of sample components and their configuration. - - The idea here is to have a united place for all materials descriptors that are not - part of the individual sample components, but rather their configuration. - - - - Array of strings referring to the names of the NXsample_components. - The order of these components serves as an index (starting at 1). - - - - - Concentration of each component - - - - - - - - Volume fraction of each component - - - - - - - - Scattering length density of each component - - - - - - - - Each component set can contain multiple components. - - - - - For description of a sub-component set. Can contain multiple components itself. - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index e0593714c..000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - Scan box and coils which deflect a beam of charged particles in a controlled manner. - - The scan box is instructed by an instance of :ref:`NXprogram`, some control software, - which is not necessarily the same program as for all components of a microscope. - - The scanbox directs the probe of charged particles (electrons, ions) - to controlled locations according to a scan scheme and plan. - - - - - Name of the typically tech-partner-specific term that specifies - an automated protocol which controls the details how the components - of the microscope work together to achieve a controlled scanning of the - beam over the sample surface. - - In most cases users do not know, have to care, or are able to disentangle the - details of the spatiotemporal dynamics of the components of the microscope. - Instead, they rely on the assumption that the microscope and control software - work as expected. Selecting then a specific scan_schema assures some level - of reproducibility in the way how the beam is scanned over the surface. - - - - - TODO discuss with the electron microscopists. - - - - - TODO discuss with the electron microscopists. - - - - - - Time period during which the beam remains at one position. - - This concept is related to term `Dwell Time`_ of the EMglossary standard. - - .. _Dwell Time: https://purls.helmholtz-metadaten.de/emg/EMG_00000015 - - - - - Time period during which the beam moves from the final position of one scan - line to the starting position of the subsequent scan line. - - This concept is related to term `Flyback Time`_ of the EMglossary standard. - - .. _Flyback Time: https://purls.helmholtz-metadaten.de/emg/EMG_00000028 - - - - - TODO discuss with the electron microscopists. - - - - - TODO discuss with the electron microscopists. - - - - - TODO discuss with the electron microscopists. - - - - - TODO discuss with the electron microscopists. - - - - - TODO discuss with the electron microscopists. - - - - - - - diff --git a/base_classes/NXsensor.nxdl.xml b/base_classes/NXsensor.nxdl.xml index 7c2e5fce3..5917c370f 100644 --- a/base_classes/NXsensor.nxdl.xml +++ b/base_classes/NXsensor.nxdl.xml @@ -55,7 +55,6 @@ - @@ -155,7 +154,6 @@ This group describes the shape of the sensor when necessary. - .. index:: plotting @@ -192,3 +190,4 @@ + diff --git a/base_classes/NXserialized.nxdl.xml b/base_classes/NXserialized.nxdl.xml deleted file mode 100644 index fda076948..000000000 --- a/base_classes/NXserialized.nxdl.xml +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - Metadata to a set of pieces of information of a resource that has been serialized. - - A typical use case is the documentation of the source (file) or database (entry) - from which pieces of information have been extracted for consumption in e.g. a - research data management system (RDMS). This may be for reasons of enabling - services such as providing access to normalized information for which reading - again from the resource may not be desired, possibe, or feasible. - - Possible reasons could be the extraction of specific information for caching, - performance reasons, or re-evaluate given pieces of information based on other - views and interaction patterns with the data where information has been formatted - differently by tools than how these pieces of information were originally - serialized. - - - - Answers into what resource the information was serialized. - - - - - - - - - Path to the resource. - - E.g. the name of a file or its absolute or relative path, or the - identifier to a resource in another database. - - - - - Value of the hash that is obtained when running algorithm - on the content of the resource referred to by path. - - - - - Name of the algorithm whereby the checksum was computed. - - - - - - Extracted file containing the serialized information. - - - diff --git a/base_classes/NXsingle_crystal.nxdl.xml b/base_classes/NXsingle_crystal.nxdl.xml deleted file mode 100644 index 44f6e92c3..000000000 --- a/base_classes/NXsingle_crystal.nxdl.xml +++ /dev/null @@ -1,72 +0,0 @@ - - - - - - Description of a single crystal material or a single crystalline phase in a material. - - There is the option of using Busing-Levy convention (as orginally designed in NXsample) - or using a more detailed description with NXrotation_set. - - - - This will follow the Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - - - - - - - - Orientation matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - - - - - - - - - UB matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is - the multiplication of the orientation_matrix, given above, - with the :math:`B` matrix which can be derived from the lattice constants. - - - - - - - - - Detailed description of single crystal orientation and misorientation. - - - - - Unit cell of the single crystal. - - - diff --git a/base_classes/NXsource.nxdl.xml b/base_classes/NXsource.nxdl.xml index 815022f88..34a5c8087 100644 --- a/base_classes/NXsource.nxdl.xml +++ b/base_classes/NXsource.nxdl.xml @@ -25,13 +25,8 @@ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd" name="NXsource" - type="group" extends="NXobject"> - - Radiation source emitting a beam. - - Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radiation (photons). - This base class can also be used to describe neutron or x-ray storage ring/facilities. - + type="group" extends="NXobject"> + The neutron or x-ray storage ring/facility. Effective distance from sample @@ -67,7 +62,6 @@ type of radiation probe (pick one from the enumerated list and spell exactly) - @@ -97,9 +91,9 @@ - Source energy. Typically, this would be the energy of - the emitted beam. For storage rings, this would be - the particle beam energy. + Source energy. + For storage rings, this would be the particle beam energy. + For X-ray tubes, this would be the excitation voltage. @@ -169,107 +163,55 @@ For storage rings, the current at the end of the most recent injection. date and time of the most recent injection. - - - The wavelength of the radiation emitted by the source. - - - - - For pulsed sources, the energy of a single pulse. - - - - - For pulsed sources, the pulse energy divided - by the pulse duration - - - - - Material of the anode (for X-ray tubes). - - - - - Filament current (for X-ray tubes). - - - - - Emission current of the generated beam. - - - - - Gas pressure inside ionization source. - - - + "Engineering" location of source. - - - The size and position of an aperture inside the source. - - - - - Deflectors inside the source. - - - - - Individual electromagnetic lenses inside the source. - - - - - - This group describes the shape of the beam line component - - + + + This group describes the shape of the beam line component + + The wavelength or energy distribution of the source - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. - The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the - z axis. + The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the + z axis. - .. image:: source/source.png - :width: 40% + .. image:: source/source.png + :width: 40% - - - - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - - - \ No newline at end of file + + + + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + + + diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 3a3476254..000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,559 +0,0 @@ - - - - - - - - - Number of spectra in the stack, for stacks the slowest dimension. - - - - - Number of image points along the slower dimension (k equivalent to z). - - - - - Number of image points along the slow dimension (j equivalent to y). - - - - - Number of image points along the fast dimension (i equivalent to x). - - - - - Number of energy bins (always the fastest dimension). - - - - - Base class container for reporting a set of spectra. - - The mostly commonly used scanning methods are supported. That is one-, - two-, three-dimensional ROIs discretized using regular Euclidean tilings. - - Use stack for all other tilings. - - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which all values in the :ref:`NXdata` - instances in this :ref:`NXspectrum_set` were loaded during parsing. - - Possibility to document from which specific other serialized resource as the source - pieces of information were processed when using NeXus as a semantic file format - to serialize that information differently. - - The group in combination with an added field *absolute_path* therein adds context. - - - - Reference to a location inside the artifact that points to the specific group of values - that were processed if the artifacts contains several groups of values and thus - further resolving of ambiguities is required. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this :ref:`NXspectrum_set` instance. - - - - - Link or name of an :ref:`NXdetector` instance with which the data were - collected. - - - - - - - - One spectrum for a point of a 0d ROI. Also known as spot measurement. - - - - Counts - - - - - - - Counts - - - - - - Energy axis - - - - - - - Energy - - - - - - - One spectrum for each point of a 1d ROI. - - - - Counts - - - - - - - - Counts - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension - - - - - - Energy axis - - - - - - - Energy - - - - - - - One spectrum for each scan point of 2d ROI. - - - - Counts - - - - - - - - - Counts - - - - - - Point coordinate along the slow dimension. - - - - - - - Point coordinate along the slow dimension. - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension. - - - - - - Energy axis - - - - - - - Energy - - - - - - - One spectrum for point of a 3d ROI. - - - - Counts - - - - - - - - - - Counts - - - - - - Point coordinate along the slower dimension. - - - - - - - Point coordinate along the slower dimension. - - - - - - Point coordinate along the slow dimension. - - - - - - - Point coordinate along the slow dimension. - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension. - - - - - - Energy axis - - - - - - - Energy - - - - - - - - Multiple instances of spectrum_0d. - - - - Counts - - - - - - - - Counts - - - - - - Group identifier - - - - - - - Group identifier - - - - - - Spectrum identifier - - - - - - - Spectrum identifier - - - - - - Energy axis - - - - - - - Energy - - - - - - - Multiple instances of spectrum_2d. - - - - Counts - - - - - - - - - - Counts - - - - - - Group identifier - - - - - - - Group identifier - - - - - - Spectrum identifier - - - - - - - Spectrum identifier - - - - - - Point coordinate along the slow dimension. - - - - - - - Point coordinate along the slow dimension. - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension. - - - - - - Energy axis - - - - - - - Energy - - - - - - - Multiple instances of spectrum_3d. - - - - Counts - - - - - - - - - - - Counts - - - - - - Group identifier - - - - - - - Group identifier - - - - - - Spectrum identifier - - - - - - - Spectrum identifier - - - - - - Point coordinate along the slower dimension. - - - - - - - Point coordinate along the slower dimension. - - - - - - Point coordinate along the slow dimension. - - - - - - - Point coordinate along the slow dimension. - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension. - - - - - - Energy axis - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index 84f83789a..000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - Base class for a stage (lab) used to hold, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Stages provide a controlled - environment around the specimen. Stages enable experimentalists to apply - controlled external stimuli on the specimen. A stage_lab is a multi-purpose - /-functional tool that is constructed from multiple actuators, sensors, - and other components. - - With such stages comes the need for storing various (meta)data - that are generated while working and modifying the sample. - - Modern stages realize a hierarchy of components. Two examples are given to help - clarify how :ref:`NXstage_lab` instances should be used: Take a specimen that is - mounted on a multi-axial tilt rotation holder. This holder is fixed in the - support unit which connects the holder to the rest of the instrument. - Evidently different components are all considerable as to represent instances - of stages. - - In another example, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit to enable - careful specimen handling. Alternatively, a microtip is a silicon post - upon which e.g. an atom probe specimen is mounted. - Multiple microtips are grouped into a microtip array to conveniently enable - loading of multiple specimens into the instrument with fewer operations. - That microtip array is fixed on a holder. Fixture units in atom probe are known - as stubs. Stubs in turn are positioned onto pucks. Pucks are then loaded onto - carousels. A carousel is a carrier unit with which eventually entire sets of - specimens can be moved in between parts of the microscope. All of these units - can be considered stage_lab instances. - - The :ref:`NXstage_lab` base class reflects this hierarchy. To cover for an as flexible - design of complex stages as possible, users should nest multiple instances of - :ref:`NXstage_lab` according to their needs to reflect the differences between what - they consider as the holder and what they consider is the stage. - The alias field can be used to specify the community jargon if necessary. - - However, a much clearer approach to reflect the hierarchy of all :ref:`NXstage_lab` - instances is postfix each instance named stage_lab with integers starting - from 1 as the top level unit. - In the microtip example one could thus use stage_lab1 for the microtip, - stage_lab2 for the microtip array, stage_lab3 holder, etc. - The depends_on keyword should be used to additional clarify the hierarchy - especially when users decide to not follow the above-mentioned postfixing - notation or when is not obvious from the postfixes which stage_lab is at - which level of the stage_lab hierarchy. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to a stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of an at least three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. A typical - example are in-situ experiments using e.g. the tools of `Protochips <https://www.protochips.com>`_. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - We are looking forward to suggestions from the scientists. - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Free-text field to give a term how that a stage_lab at this level of the - stage_lab hierarchy is commonly referred to. Examples could be stub, - puck, carousel, microtip, clip, holder, etc. - - - - - The interpretation of this tilt should be specialized - and thus detailed via the application definition. - - - - - The interpretation of this tilt should be specialized - and thus detailed via the application definition. - - - - - The interpretation of this rotation should be specialized - and thus detailed via the application definition. - - - - - The interpretation of this position should be specialized - and thus detailed via the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - - diff --git a/base_classes/NXsubentry.nxdl.xml b/base_classes/NXsubentry.nxdl.xml index 726080c20..2a95f4501 100644 --- a/base_classes/NXsubentry.nxdl.xml +++ b/base_classes/NXsubentry.nxdl.xml @@ -83,7 +83,7 @@ Extended title for entry - + Unique identifier for the experiment, defined by the facility, possibly linked to the proposals @@ -95,13 +95,13 @@ Description of the full experiment (document in pdf, latex, ...) - + User or Data Acquisition defined group of NeXus files or :ref:`NXentry` Brief summary of the collection, including grouping criteria. - + unique identifier for the measurement, defined by the facility. @@ -185,4 +185,5 @@ - \ No newline at end of file + + diff --git a/base_classes/NXsubstance.nxdl.xml b/base_classes/NXsubstance.nxdl.xml deleted file mode 100644 index 6d246ca22..000000000 --- a/base_classes/NXsubstance.nxdl.xml +++ /dev/null @@ -1,119 +0,0 @@ - - - - - - A form of matter with a constant, definite chemical composition. - - Examples can be single chemical elements, chemical compunds, or alloys. - For further information, see https://en.wikipedia.org/wiki/Chemical_substance. - - - - User-defined chemical name of the substance - - - - - Molecular mass of the substance - - - - - Unique numeric CAS REGISTRY number of the sample chemical content - For further information, see https://www.cas.org/. - - - - - CAS REGISTRY name of the sample chemical content - - - - - CAS REGISTRY URI - - - - - CAS REGISTRY image - - - - - Synonyms in the CAS system. - - - - - String InChi identifier. - The InChI identifier expresses chemical structures in terms of atomic connectivity, - tautomeric state, isotopes, stereochemistry and electronic charge in order to - produce a string of machine-readable characters unique to the respective molecule. - For further information, see https://iupac.org/who-we-are/divisions/division-details/inchi/. - - - - - Condensed, 27 character InChI key. - Hashed version of the full InChI (using the SHA-256 algorithm). - - - - - Name according to the IUPAC system (standard). - For further information, see https://iupac.org/. - - - - - Identifier in the SMILES (Simplified Molecular Input Line Entry System) system - For further information, see https://www.daylight.com/smiles/. - - - - - Canonical version of the smiles identifier - - - - - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard:107 - This is the *Hill* system used by Chemical Abstracts. - - * Only recognized element symbols may be used. - * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. - * A space or parenthesis must separate each cluster of (element symbol + count). - * Where a group of elements is enclosed in parentheses, the multiplier for the - group must follow the closing parentheses. That is, all element and group - multipliers are assumed to be printed as subscripted numbers. - * Unless the elements are ordered in a manner that corresponds to their chemical - structure, the order of the elements within any group or moiety depends on - whether or not carbon is present. - * If carbon is present, the order should be: - - C, then H, then the other elements in alphabetical order of their symbol. - - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. - - - diff --git a/base_classes/NXtransformations.nxdl.xml b/base_classes/NXtransformations.nxdl.xml index fd40f89e4..c8337ce72 100644 --- a/base_classes/NXtransformations.nxdl.xml +++ b/base_classes/NXtransformations.nxdl.xml @@ -170,9 +170,8 @@ - Points to the path of a field defining the axis on which this instance of - NXtransformations depends or the string ".". It can also point to an instance of - ``NX_coordinate_system`` if this transformation depends on it. + Points to the path to a field defining the axis on which this + depends or the string ".". @@ -203,7 +202,7 @@ the corresponding axis moves during the exposure of a frame. Ideally, the value of this field added to each value of ``AXISNAME`` would agree with the corresponding values of ``AXISNAME_end``, but there is a possibility of significant - differences. Use of ``AXISNAME_end`` is recommended. + differences. Use of ``AXISNAME_end`` is recommended. @@ -219,4 +218,4 @@ for a summary of the discussion. - \ No newline at end of file + diff --git a/base_classes/NXuser.nxdl.xml b/base_classes/NXuser.nxdl.xml index e014584c2..607d50e90 100644 --- a/base_classes/NXuser.nxdl.xml +++ b/base_classes/NXuser.nxdl.xml @@ -66,13 +66,12 @@ address/contact database - - - Details about an author code, open researcher, or contributor - (persistent) identifier, e.g. defined by https://orcid.org and expressed - as a URI. - - + + + an author code, Open Researcher and Contributor ID, + defined by https://orcid.org and expressed as a URI + + .. index:: plotting @@ -86,4 +85,5 @@ for a summary of the discussion. - \ No newline at end of file + + diff --git a/base_classes/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml similarity index 62% rename from base_classes/NXaberration.nxdl.xml rename to contributed_definitions/NXaberration.nxdl.xml index 44160b54f..3c784de1b 100644 --- a/base_classes/NXaberration.nxdl.xml +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -1,10 +1,10 @@ - + - + Quantified aberration coefficient in an aberration_model. - - - Value of the aberration coefficient. - - - + + - Uncertainty of the value of the aberration coefficient - according to uncertainty_model. + Confidence - + - How was the uncertainty quantified e.g. via the 95% confidence interval - and using which algorithm or statistical model. + 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 + For the CEOS definitions the C aberrations are radial-symmetric and have no + angle entry, while the A, B, D, S, or R aberrations are n-fold symmetric and have an angle entry. For the NION definitions the coordinate system differs to the one used in CEOS and instead two aberration coefficients a and b are used. - - - Given name to this aberration. - - - - - Alias also used to name and refer to this specific type of aberration. - - + + diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml new file mode 100644 index 000000000..c340fc2ae --- /dev/null +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -0,0 +1,105 @@ + + + + + + Models for aberrations of electro-magnetic lenses in electron microscopy. + + See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) + for different definitions available and further details. Table 7-2 of Ibid. + publication (page 305ff) documents how to convert from the NION to the + CEOS definitions. + + + + + + + + + + + Defocus + + + + + Two-fold astigmatism + + + + + Two-fold astigmatism + + + + + Second-order axial coma + + + + + Second-order axial coma + + + + + Threefold astigmatism + + + + + Threefold astigmatism + + + + + Spherical aberration + + + + + Star aberration + + + + + Star aberration + + + + + Fourfold astigmatism + + + + + Fourfold astigmatism + + + + + Fifth-order spherical aberration + + + diff --git a/contributed_definitions/NXaberration_model_ceos.nxdl.xml b/contributed_definitions/NXaberration_model_ceos.nxdl.xml new file mode 100644 index 000000000..584ef6c55 --- /dev/null +++ b/contributed_definitions/NXaberration_model_ceos.nxdl.xml @@ -0,0 +1,91 @@ + + + + + + CEOS definitions/model for aberrations of electro-magnetic lenses. + + See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) + for different definitions available and further details. Table 7-2 of Ibid. + publication (page 305ff) documents how to convert from the NION to the + CEOS definitions. + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXaberration_model_nion.nxdl.xml b/contributed_definitions/NXaberration_model_nion.nxdl.xml new file mode 100644 index 000000000..cb74995dd --- /dev/null +++ b/contributed_definitions/NXaberration_model_nion.nxdl.xml @@ -0,0 +1,63 @@ + + + + + + NION definitions/model for aberrations of electro-magnetic lenses. + + See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) + for different definitions available and further details. Table 7-2 of Ibid. + publication (page 305ff) documents how to convert from the NION to the + CEOS definitions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml b/contributed_definitions/NXadc.nxdl.xml similarity index 67% rename from base_classes/NXcg_triangulated_surface_mesh.nxdl.xml rename to contributed_definitions/NXadc.nxdl.xml index da55b2530..b3edd70bc 100644 --- a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/contributed_definitions/NXadc.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computational geometry description of a mesh of triangles. - - The mesh may be self-intersecting and have holes but the - triangles used must not be degenerated. + Analog-to-digital converter component/integrated circuit. - + - A graph-based approach to describe the mesh when it is also desired - to perform topological processing or analyses on the mesh. + TBD. - + diff --git a/contributed_definitions/NXamplifier.nxdl.xml b/contributed_definitions/NXamplifier.nxdl.xml deleted file mode 100644 index c9b719a7b..000000000 --- a/contributed_definitions/NXamplifier.nxdl.xml +++ /dev/null @@ -1,91 +0,0 @@ - - - - - - Base classed definition for amplifier devices. - - - - (IC, device) (NXmanufacturer?) - - - - - The number of preamplifier channels are assgined. - - - - - The number of preamplifier channels are ready tp to be used. (array for active - channels) - - - - - The output signal does not go through a feedback loop to adjust the - amplification of the amplifier. (array for active channels) - - - - - - The ratio of the amplitue of the useful signal to the amplitude of the noise in - the output signal of the amplifier. S/N=V_signal/V_noise. (array for active - channels) - - - - - (if active >1) - - - - - for reducing interferences between different signalling pathways - - - - - The spectrum of frequency it can amplify, from its lowest to highest frequency - limits. - - - - - Order and cut-off frequency of the low-pass filter applied on the demodulated - signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) - - - - - Order and cut-off frequency of the high-pass filter applied on the demodulation - signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) - - - - diff --git a/base_classes/NXactivity.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml similarity index 53% rename from base_classes/NXactivity.nxdl.xml rename to contributed_definitions/NXaperture_em.nxdl.xml index f354de06d..84a36254c 100644 --- a/base_classes/NXactivity.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -21,36 +21,39 @@ # # For further information, see http://www.nexusformat.org --> - + + - A planned or unplanned action that has a temporal extension and for some time depends on some entity. - - This class is planned be used in the future as the super class for all other activities if inheritance - in base classes is supported in NeXus. + Details of an individual aperture for beams in electron microscopy. - + - ISO 8601 formatted time code (with local time zone offset to UTC information - included) when this activity started. + Given name/alias of the aperture. - + - ISO 8601 formatted time code (with local time zone offset to UTC information - included) when this activity ended. + Relevant value from the control software. + + This is not always just the diameter of (not even in the case) + of a circular aperture. Usually it is a mode setting value which + is selected in the control software. + Which settings are behind the value should be defined + for now in the description field, if these are known + in more detail. - Short description of the activity. + Ideally, a (globally) unique persistent identifier, link, or text to a + resource which gives further details. Alternatively a free-text field. - + + - This can be any data or other descriptor acquired during the activity - (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. 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/NXapm_composition_space_results.nxdl.xml b/contributed_definitions/NXapm_composition_space_results.nxdl.xml new file mode 100644 index 000000000..15c107dc4 --- /dev/null +++ b/contributed_definitions/NXapm_composition_space_results.nxdl.xml @@ -0,0 +1,488 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of voxel of discretized domain for analyzed part of the dataset. + + + + + The dimensionality of the grid. + + + + + The cardinality or total number of cells/grid points. + + + + + Number of terms in the composition clustering dictionary + + + + + Number of terms in the position clustering dictionary + + + + + Results of a run with Alaukik Saxena's composition space tool. + + This is an initial draft application definition for the common NFDI-MatWerk, + FAIRmat infrastructure use case IUC09 how to improve the organization and + results storage of the composition space tool and make these data at the same + time directly understandable for NOMAD. + + This draft does no contain yet the annotations for how to also store + in the HDF5 file a default visualization whereby the composition grid + could directly be explored using H5Web. I am happy to add this ones the + data have been mapped on this schema, i.e. more discussion needed. + + Also iso-surfaces can be described, for paraprobe, this is a solved problem, + check the respective group in the NXapm_paraprobe_results_nanochem data + schema/application definition. + + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + + + + + + TBD, maybe how to link between pyiron state tracking and app state tracking + + + + + Disencouraged place for free-text for e.g. comments. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. when composition space tool was started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and composition space tool exited as a process. + + + + + The path and name of the config file for this analysis. + TBD, this can be e.g. Alaukik's YAML file for composition space. + + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + + The path and name of the file (technology partner or community format) + from which reconstructed ion positions were loaded. + + + + + + + + The path and name of the file (technology partner or community format + from which ranging definitions, i.e. how to map mass-to- + charge-state ratios on iontypes were loaded. + + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the executable managed to process the analysis + or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Some suggestions follow, e.g. that field names should be prefixed + with the following controlled terms indicating which individual + coordinate system is described: + + * world + * composition_space + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + + + + + Position of each cell in Euclidean space. + + + + + + + + + + + + + + + + For each ion, the identifier of the voxel in which the ion is located. + + + + + + + + + + + + + + + + + + In Alaukik's tool the GMM step. + + + + + + + + + The keywords of the dictionary of distinguished compositionally- + defined cluster, e.g. the phases. Examples for keywords could be + phase1, phase2, and so one and so forth. + + + + + + + + Resolves for each keyword in cluster_dict which integer is used to + label something that it belongs or is assumed to represent this + cluster. + + + + + + + + + For example if the voxel grid is used to report that there + are voxels which are assumed to represent volume of either phase1 + or phase2, the cluster_dict_keyword would be a list with two names + phase1 and phase2, respectively. The cluster_dict_value would be a + list of e.g. integers 1 and 2. These could be used to build an + array with as many entries as there are voxel and store in this array + the respective value to encode which phase is assumed for each voxel. + + + + + + + + + + In Alaukik's tool the DBScan step after the GMM step. + + + + + + + + + The keywords of the dictionary of distinguished spatially-contiguous + clusters. Examples for keywords could be precipitate1, precipitate2, + and so one and so forth. + + + + + + + + Resolves for each keyword in cluster_dict which integer is used to + label something that it belongs or is assumed to represent this + cluster. + + + + + + + + + For example if the voxel grid is used to report that there + are voxels which are assumed to represent volume of certain precipitates, + say we found ten precipitates and consider the rest as matrix. + We could make a list of say matrix, precipitate1, precipitate2, ..., + precipitate10. With cluster_dict_value then running from 0 to 10, + i.e. matrix is flagged special as 0 and the remaining particles + are indexed conveniently as 1, 2, ..., 10 like end users expect. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml deleted file mode 100644 index 923e1a137..000000000 --- a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml +++ /dev/null @@ -1,191 +0,0 @@ - - - - - - Application definition for a configuration of the CompositionSpace tool used in atom probe. - - * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ - - This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure - use case IUC09 that explores how to improve the organization and results storage of the - CompositionSpace software using NeXus. - - - - - - - - - - - - - - - Specification of the tomographic reconstruction used for this analysis. - Typically, reconstructions in the field of atom probe tomography are communicated via - files which store at least reconstructed ion positions and mass-to-charge-state-ratio - values. Container files like HDF5 though can store multiple reconstructions. - Therefore, the position and mass_to_charge concepts point to specific instances - to use for this analysis. - - - - - - - - Name of the node which resolves the reconstructed - ion position values to use for this analysis. - - - - - Name of the node which resolves the mass-to-charge-state ratio - values for each reconstructed ion to use for this analysis. - - - - - - Specification of the ranging definitions used for this analysis. - - Indices start from 1. The value 0 is reserved for the null model of unranged positions whose - iontype is unknown_type. The value 0 is also reserved for voxels that lie outside the dataset. - - - - - - - - Name of the (parent) node directly below which the ranging definitions for - (molecular) ions are stored. - - - - - - Step during which the point cloud is discretized to compute element-specific composition fields. - Iontypes are atomically decomposed to correctly account for the multiplicity of each element that - was ranged for each ion. - - - - Edge length of cubic voxels building the 3D grid that is used for discretizing - the point cloud. - - - - - - Optional step during which the subsequent segmentation step is prepared with the aim to eventually - reduce the dimensionality of the chemical space in which the machine learning model works. - - In this step a supervised reduction of the dimensionality of the chemical space is quantified using - the (Gini) feature importance of each element to suggest which columns of the composition matrix - should be taken for the subsequent segmentation step. - - - - Was the automated phase assignment used? - - - - - Estimated guess for which a Gaussian mixture model is evaluted to preprocess a result that - is subsequenty post-processed with a random_forest_classifier to lower the number of - dimensions in the chemical space to the subset of trunc_species many elements with the - highest feature importance. - - - - - The number of elements to use for reducing the dimensionality. - - - - - Configuration for the random forest classification model. - - - - - - Step during which the voxel set is segmented into voxel sets with different - chemical composition. - - - - A principal component analysis of the chemical space to guide a decision into how many sets of voxels - with different chemical composition the machine learning algorithm suggests to split the voxel set. - - - - - The decision is guided through the evalution of the information criterion - minimization. - - - - The maximum number of chemical classes to probe with the Gaussian mixture model - with which the voxel set is segmented into a mixture of voxels with that many different - chemical compositions. - - - - - Configuration for the Gaussian mixture model that is used in the segmentation - step. - - - - - - - Step during which the chemically segmented voxel sets are analyzed for their - spatial organization. - - - - Configuration for the DBScan algorithm that is used in the clustering step. - - - - The maximum distance between voxel pairs in a neighborhood to be considered - connected. - - - - - The number of voxels in a neighborhood for a voxel to be considered as a core - point. - - - - - - - diff --git a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml deleted file mode 100644 index 7bf1c7912..000000000 --- a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml +++ /dev/null @@ -1,390 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the grid. - - - - - Total number of voxels. - - - - - Total number of ions in the reconstructed dataset. - - - - - Application definition for results of the CompositionSpace tool used in atom probe. - - * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ - - This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure - use case IUC09 that explores how to improve the organization and results storage of the - CompositionSpace software using NeXus. - - - - - - - - - - - - - - - - - - - - - - Configuration file that was used in this analysis. - - - - - - - - - - - Step during which the point cloud is discretized to compute element-specific composition fields. - Iontypes are atomically decomposed to correctly account for the multiplicity of each element that - was ranged for each ion. - - Using a discretization grid that is larger than the average distance between reconstructed ion positions - reduces computational costs. This is the key idea of the CompositionSpace tool compared to other methods - used in atom probe for characterizing microstructural features using the ion position data directly. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Position of each cell in Euclidean space. - - - - - - - - - Discrete coordinate of each voxel. - - - - - - - - - - For each ion, the identifier of the voxel into which the ion binned. - - - - - - - - - Total number of weight (counts for discretization with a rectangular transfer function) - for the occupancy of each voxel with atoms. - - - - - - - - - Chemical symbol of the element from the periodic table. - - - - - Element-specific weight (counts for discretization with a rectangular transfer function) - for the occupancy of each voxel with atoms of this element. - - - - - - - - - - Optional step during which the subsequent segmentation step is prepared to - improve the segmentation. - - - - - - - - - - - - - - Element identifier stored sorted in descending order of feature importance. - - - - - - - Axis caption - - - - - - Element relative feature importance stored sorted in descending order of feature - importance. - - - - - - - Axis caption - - - - - - - - Step during which the voxel set is segmented into voxel sets with different - chemical composition. - - - - PCA in the chemical space (essentially composition correlation analyses). - - - - - - - - - - - - - - - Explained variance values - - - - - - - - Elements identifier matching those from ENTRY/voxelization/elementID as the - principal component analysis. - - - - - - - - - - Information criterion minimization. - - - - - - - - - - Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. - - - - n_components argument of the Gaussian mixture model. - - - - - y_pred return values of the computation. - - - - - - - - - Information criterion as a function of number of n_ic_cluster aka dimensions. - - - - - - - - Akaike information criterion values - - - - - - - - Bayes information criterion values - - - - - - - - Actual n_ic_cluster values used - - - - - - - - - - - Step during which the chemically segmented voxel sets are analyzed for their spatial organization - into different spatial clusters of voxels in the same chemical set but representing individual object - not-necessarily watertight or topologically closed objects built from individual voxels. - - - - - - - - - - Respective DBScan clustering result for each segmentation/ic_opt case. - - - - - - The maximum distance between voxel pairs in a neighborhood to be considered - connected. - - - - - The number of voxels in a neighborhood for a voxel to be considered as a core - point. - - - - - Raw label return values - - - - - - - - Voxel identifier - - Using these identifiers correlated element-wise with the values in the label array - specifies for which voxel in the grid clusters from this process were found. - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_input_ranging.nxdl.xml b/contributed_definitions/NXapm_input_ranging.nxdl.xml new file mode 100644 index 000000000..b82a78e70 --- /dev/null +++ b/contributed_definitions/NXapm_input_ranging.nxdl.xml @@ -0,0 +1,63 @@ + + + + + + + Metadata to ranging definitions made for a dataset in atom probe microscopy. + + Ranging is the process of labeling time-of-flight data with so-called iontypes + which ideally specify the most likely ion/molecular ion evaporated within a + given mass-to-charge-state-ratio value interval. + + The paraprobe-toolbox uses the convention that the so-called UNKNOWNTYPE + iontype (or unranged ions) represents the default iontype. + The ID of this special iontype is always reserved as 0. Each ion + is assigned to the UNKNOWNTYPE by default. Iontypes are assigned + by checking if the mass-to-charge-state-ratio values of an ion matches + to any of the defined mass-to-charge-state-ratio intervals. + + + + Path and name of the NeXus/HDF5 file which stores ranging definitions. + + + + Version identifier of the file (representing an at least SHA256 strong) + hash. Such hashes serve reproducibility as they can be used for tracking + provenance metadata in a workflow. + + + + + + Name of the group (prefix to the individual ranging definitions) inside + the file referred to by filename which points to the specific ranging + definition to use. + An HDF5 file can store multiple ranging definitions. Using an ID is + the mechanism to distinguish which specific ranging (version) will + be processed. Reconstruction and ranging IDs can differ. + They specify different IDs. + + + diff --git a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml new file mode 100644 index 000000000..8ed7b9002 --- /dev/null +++ b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml @@ -0,0 +1,58 @@ + + + + + + + Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. + + + + Name of the (NeXus)/HDF5 file which stores reconstructed ion position + and mass-to-charge-state ratios. Such an HDF5 file can store multiple + reconstructions. Using the information within the dataset_name fields + is the mechanism whereby paraprobe decides which reconstruction to + process. With this design it is possible that the same HDF5 + file can store multiple versions of a reconstruction. + + + + Version identifier of the file (representing an at least SHA256 strong) + hash. Such hashes serve reproducibility as they can be used for tracking + provenance metadata in a workflow. + + + + + + Name of the dataset inside the HDF5 file which refers to the + specific reconstructed ion positions to use for this analysis. + + + + + Name of the dataset inside the HDF5 file which refers to the + specific mass-to-charge-state-ratio values to use for this analysis. + + + diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml deleted file mode 100644 index 21897a43b..000000000 --- a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml +++ /dev/null @@ -1,384 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - - Maximum number of atoms per molecular ion. Should be 32 for paraprobe. - - - - - Number of clustering algorithms used. - - - - - Number of different iontypes to distinguish during clustering. - - - - - Application definition for a configuration file of the paraprobe-clusterer tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. - - - - - - - - - - - How many cluster_analysis tasks should the tool execute. - - - - - This process maps results from a cluster analysis made with IVAS / AP Suite - into an interoperable representation. IVAS / AP Suite usually exports such results - as a list of reconstructed ion positions with one cluster label per position. - These labels are reported via the mass-to-charge-state-ratio column of what is effectively - a binary file that is formatted like a POS file but cluster labels written out using floating - point numbers. - - - - - - - - - - - - File with the results of the cluster analyses that was computed with IVAS / AP suite - (e.g. maximum-separation method clustering algorithm `J. Hyde et al. <https://doi.org/10.1557/PROC-650-R6.6>`_). - The information is stored in an improper (.indexed.) POS file as a matrix of floating - point quadruplets, one quadruplet for each ion. The first three values of each - quadruplet encode the position of the ion. The fourth value is the integer identifier - of the cluster encoded as a floating point number. - - - - - - - - - Specifies if paraprobe-clusterer should use the evaporation_ids from reconstruction - for recovering for each position in the :ref:`NXserialized` results the closest matching position - (within floating point accuracy). This can be useful when users wish to recover the - original evaporation_id, which IVAS /AP Suite drops when writing their *.indexed.* cluster - results POS files that is referred to results. - - - - - - - This process performs a cluster analysis on a - reconstructed dataset or a ROI within it. - - - - - - - - - - - - - - - - - - - Distance between each ion and triangulated surface mesh. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - How should iontypes be considered during the cluster analysis. - - The value resolve_all will set an ion active - in the analysis regardless of which iontype it is. - - The value resolve_unknown will set an ion active - when it is of the UNKNOWNTYPE. - - The value resolve_ion will set an ion active - if it is of the specific iontype, irregardless of its nuclide structure. - - The value resolve_element will set an ion active and account as many times - for it, as the (molecular) ion contains atoms of elements in the whitelist - ion_query_nuclide_vector. - - The value resolve_isotope will set an ion active and account as many times - for it, as the (molecular) ion contains nuclides in the whitelist - ion_query_nuclide_vector. - - In effect, ion_query_nuclide_vector acts as a whitelist to filter which ions are - considered as source ions of the correlation statistics and how the multiplicity - of each ion will be factorized. - - This is relevant as in atom probe we have the situation that an ion of a molecular - ion with more than one nuclide, say Ti O for example is counted potentially several - times because at that position (reconstructed) position it has been assumed that - there was a Ti and an O atom. This multiplicity affects the size of the feature and its - chemical composition. - - - - - - - - - Matrix of nuclide vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - - - - - - - - - - Settings for DBScan clustering algorithm. For original details about the - algorithm and (performance-relevant) details consider: - - * `M. Ester et al. <https://dx.doi.org/10.5555/3001460.3001507>`_ - * `M. Götz et al. <https://dx.doi.org/10.1145/2834892.2834894>`_ - - For details about how the DBScan algorithms is the key behind the - specific modification known as the maximum-separation method in the - atom probe community consider `E. Jägle et al. <https://dx.doi.org/10.1017/S1431927614013294>`_ - - - - Strategy how a set of cluster analyses with different parameter is executed: - - * For tuple as many runs are performed as parameter values have been defined. - * For combinatorics individual parameter arrays are looped over. - - As an example we may provide ten entries for eps and three entries for min_pts. - If high_throughput_method is set to tuple, the analysis is invalid because we have - an insufficient number of min_pts values to pair them with our ten eps values. - By contrast, if high_throughput_method is set to combinatorics, the tool will run three - individual min_pts runs for each eps value, resulting in a total of 30 analyses. - - A typical example from the literature `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ - can be instructed via setting eps to an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True), - one min_pts value that is equal to 1, and high_throughput_method set to combinatorics. - - - - - - - - - Array of epsilon (eps) parameter values. - - - - - - - - Array of minimum points (min_pts) parameter values. - - - - - - - - - - Settings for the HPDBScan clustering algorithm. - - * L. McInnes et al. <https://dx.doi.org/10.21105/joss.00205>`_ - * scikit-learn hdbscan library `<https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html>`_ - - See also this documentation for details about the parameter. - Here we use the terminology of the hdbscan documentation. - - - - Strategy how runs with different parameter values are composed, - following the explanation for higih_throughput_method of dbscan. - - - - - - - - - Array of min_cluster_size parameter values. - - - - - - - - Array of min_samples parameter values. - - - - - - - - Array of cluster_selection parameter values. - - - - - - - - Array of alpha parameter values. - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml deleted file mode 100644 index 763a37b1c..000000000 --- a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml +++ /dev/null @@ -1,299 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - Number of clusters found. - - - - - Application definition for results files of the paraprobe-spatstat tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - - - - - - - - - - - - - - - - - - - - - - - - - - - Results of a DBScan clustering analysis. - - - - The epsilon (eps) parameter used. - - - - - The minimum points (min_pts) parameter used. - - - - - Number of members in the set which is partitioned into features. - Specifically, this is the total number of targets filtered from the - dataset, i.e. typically the number of clusters which is usually not and - for sure not necessarily the total number of ions in the dataset. - - - - - Which identifier is the first to be used to label a cluster. - - The value should be chosen in such a way that special values can be resolved: - * 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 the value of -1 and points of the - unassigned category get the value 0. - - - - - The evaporation (sequence) identifier (aka evaporation_id) to figure out - which ions from the reconstruction were considered targets. The length - of this array is not necessarily n_ions. - Instead, it is the value of cardinality. - - - - - - - - - The number of solutions found for each target. Typically, - this value is 1 in which case the field can be omitted. - Otherwise, this array is the concatenated set of values of solution - tuples for each target that can be used to decode model_labels, - core_sample_indices, and weight. - - - - - - - - The raw labels from the DBScan clustering backend process. - The length of this array is not necessarily n_ions. - Instead, it is typically the value of cardinality provided that each - target has only one associated cluster. If targets are assigned to - multiple cluster this array is as long as the total number of solutions - found and - - - - - - - - The raw array of core sample indices which specify which of the - targets are core points. - - - - - - - - Numerical label for each target (member in the set) aka cluster identifier. - - - - - - - - Categorical label(s) for each target (member in the set) aka cluster name(s). - - - - - - - - Weights for each target that specifies how probable the target is assigned to - a specific cluster. - - For the DBScan algorithm and atom probe tomography this value is the - multiplicity of each ion with respect to the cluster. That is how many times - should the position of the ion be accounted for because the ion is e.g. a - molecular ion with several elements or nuclides of requested type. - - - - - - - - - Are targets assigned to the noise category or not. - - - - - - - - - Are targets assumed a core point. - - - - - - - - In addition to the detailed storage which members were grouped to which - feature here summary statistics are stored that communicate e.g. how many - cluster were found. - - - - - Total number of targets in the set, i.e. ions that were filtered - and considered in this cluster analysis. - - - - - Total number of members in the set which are categorized as noise. - - - - - Total number of members in the set which are categorized as a core point. - - - - - Total number of clusters (excluding noise and unassigned). - - - - - - Numerical identifier of each feature aka cluster_identifier. - - - - - - - - Number of members for each feature. - - - - - - - - - - - - - - - - - - - - - - - - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml new file mode 100644 index 000000000..4f1373923 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml @@ -0,0 +1,477 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + Maximum number of atoms per molecular ion. Should be 32 for paraprobe. + + + + + Number of clustering algorithms used. + + + + + Number of different iontypes to distinguish during clustering. + + + + + Configuration of a paraprobe-clusterer tool run in atom probe microscopy. + + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + How many tasks to perform? + + + + + This process maps results from cluster analyses performed with IVAS/APSuite + into an interoperable representation. Specifically in this process + paraprobe-clusterer takes results from clustering methods from other tools + of the APM community, like IVAS/APSuite. These results are usually reported + in two ways. Either as an explicit list of reconstructed ion positions. + In the case of IVAS these positions are reported through a text file + with a cluster label for each position. + + Alternatively, the list of positions is reported, as it is the case for + AMETEK (IVAS/AP Suite) but the cluster labels are specified implicitly + only in the following way: The mass-to-charge-state ratio column of a + what is effectively a file formatted like POS is used to assign a hypothetical + mass-to-charge value which resolves a floating point representation + of the cluster ID. + + Another case can occur where all disjoint floating point values, + i.e. here cluster labels, are reported and then a dictionary is created + how each value matches to a cluster ID. + + In general the cluster ID zero is reserved for marking the dataset + as to not be assigned to any cluster. Therefore, indices of disjoint + clusters start at 1. + + + + + + + + + AMETEK/Cameca results of cluster analyses, like with the maximum- + separation (MS) method clustering algorithm `J. Hyde et al. <https://doi.org/10.1557/PROC-650-R6.6>`_ + are stored as an improper POS file: This is a matrix of floating + point quadruplets, one for each ion and as many quadruplets as + ions were investigated. The first three values encode the position + of the ion. The fourth value is an improper mass-to-charge-state-ratio + value which encodes the integer identifier of the cluster as a floating + point number. + + + + + + + Specifies if the tool should try to recover for each position the closest + matching position from dataset/dataset_name_reconstruction (within + floating point accuracy). This can be useful for instance when users + wish to recover the original evaporation ID, which IVAS/AP Suite drops + for instance when writing their *.indexed.* cluster results POS files. + + + + + + + This process performs a cluster analysis on a reconstructed dataset + or a portion of the reconstruction. + + + + + + + + + + + + + + + + + The tool enables to inject precomputed distance information for each + point/ion which can be used for further post-processing and analysis. + + + + Name of an HDF5 file which contains the ion distances. + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + Absolute HDF5 path to the dataset with distance values for each ion. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + How should iontypes be interpreted/considered during the cluster analysis. + Different options exist how iontypes are interpreted (if considered at all) + given an iontype represents in general a (molecular) ion with different isotopes + that have individually different multiplicity. + + The value resolve_all will set an ion active in the analysis + regardless of which iontype it is. + The value resolve_unknown will set an ion active when it is of the + UNKNOWNTYPE. + The value resolve_ion will set an ion active if it is of the + specific iontype, irregardless of its elemental or isotopic details. + The value resolve_element will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + The value resolve_isotope will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains isotopes + in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized. + + This is relevant as in atom probe we have the situation that a ion + of a molecular ion with more than one nuclid, say Ti O for example + is counted such that although there is a single TiO molecular ion + at a position that the cluster has two members. This multiplicity + affects the size of the feature and chemical composition. + + + + + + + + + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. + + + + + + + + + Settings for DBScan clustering algorithm. For original details about the + algorithms and (performance-relevant) details consider: + + * `M. Ester et al. <https://dx.doi.org/10.5555/3001460.3001507>`_ + * `M. Götz et al. <https://dx.doi.org/10.1145/2834892.2834894>`_ + + For details about how the DBScan algorithms is the key behind the + specific modification known as the maximum-separation method in the + atom probe community consider `E. Jägle et al. <https://dx.doi.org/10.1017/S1431927614013294>`_ + + + + Strategy how runs are performed with different parameter: + + * For tuple as many runs are performed as parameter values. + * For combinatorics individual parameter arrays are looped over. + + As an example we may define eps with ten entries and min_pts with + three entries. If high_throughput_method is tuple the analysis is + invalid as we have an insufficient number of min_pts for the ten + eps values. + By contrast, for combinatorics paraprobe-clusterer will run three + individual min_pts runs for each eps value, resulting in a total + of 30 analyses. + As an example the DBScan analysis reported in `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ + would have defined an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True) + eps values, min_pts one, and high_throughput_method set to combinatorics. + + + + + + + + + Array of epsilon (eps) parameter values. + + + + + + + + Array of minimum points (min_pts) parameter values. + + + + + + + + + + Settings for the OPTICS clustering algorithm. + + * `M. Ankerest et al. <https://dx.doi.org/10.1145/304181.304187>`_ + + + + Strategy how runs are performed with different parameter: + + * For tuple as many runs are performed as parameter values. + * For combinatorics individual parameter arrays are looped over. + + See the explanation for the corresponding parameter for dbscan + processes above-mentioned for further details. + + + + + + + + + Array of minimum points (min_pts) parameter values. + + + + + + + + Array of maximum epsilon (eps) parameter values. + + + + + + + + + Settings for the HPDBScan clustering algorithm. + + * L. McInnes et al. <https://dx.doi.org/10.21105/joss.00205>`_ + * scikit-learn hdbscan library `<https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html>`_ + + See also this documentation for details about the parameter. + Here we use the terminology of the hdbscan documentation. + + + + Strategy how runs are performed with different parameter: + + * For tuple as many runs are performed as parameter values. + * For combinatorics individual parameter arrays are looped over. + + See the explanation for the corresponding parameter for dbscan + processes above-mentioned for further details. + + + + + + + + + Array of min_cluster_size parameter values. + + + + + + + + Array of min_samples parameter values. + + + + + + + + Array of cluster_selection parameter values. + + + + + + + + Array of alpha parameter values. + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml new file mode 100644 index 000000000..4a24598fe --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml @@ -0,0 +1,257 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Configuration/settings of a paraprobe-distancer software tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + How many individual analyses should the tool execute. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Compute for all filtered points, e.g. ions of the point set + the shortest Euclidean distance to the closest triangle of the + set of triangles. The triangles can formed a closed surface mesh. + Distances are not simple distances based on normal projections but + giving an exact solution. + + + + + Paraprobe-distancer enables the computation of the Euclidean shortest + distance for each member of a set of points against a set of triangles. + In contrast to comparable methods used in atom probe the here computed + distance is not simply the projected distance to one of the triangles + but the more costly but robust computation of the distance between + a point and a triangle. + + The triangles can represent for instance the facets of a triangulated + surface mesh of a model for the edge of the dataset. Such a model can + be computed with paraprobe-surfacer. Alternatively, the triangles can + be those from the set of all facets for a set of convex hulls, alpha-shapes, + or alpha wrappings about three-dimensional objects like precipitates + (computed with e.g. paraprobe-nanochem). + + Currently, the tool does not check if the respectively specified + triangle sets are consistent, what their topology is, or whether or + not they are consistently oriented. + Each dataset that is referred to in the list_of _dataset_names_vertices + should be an (Nvertices, 3) array of NX_FLOAT. Each dataset referred + to in the list_of_dataset_names_facet_indices should be an + (Nfacets, 3) array of NX_UINT. + Facet indices refer to vertex indices. These need to start at zero + and must not exceed Nvertices - 1, i.e. the identifier_offset is 0 + and vertices are indexed thus implicitly. + Facet normal vectors have to be also an array + of shape (Nfacets, 3) of NX_FLOAT. + + + + How many triangle sets to consider. + + + + + List of triangle sets. This design allows users to combine + multiple triangle sets. + + + + Name of the HDF5 file(s) which contain(s) vertex coordinates + and facet indices to describe the desired set of triangles. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility. + + + + + + Absolute HDF5 path to the dataset which + specifies the array of vertex positions. + + + + + Absolute HDF5 path to the dataset which + specifies the array of facet indices. + + + + + Absolute HDF5 path to the dataset which + specifies the array of facet normal vectors. + + + + + + + Specifies for which ions/points the tool will compute distances. + The purpose of this setting is to avoid unnecessary computations + when the user requests to only compute distances of ions within a + threshold distance to the triangle soup. + + By default the distances are computed for all ions; however + the setting skin enables to compute distances only for those + ions which are not farther away located to a triangle + than threshold_distance. + + + + + + + + + + Maximum distance for which distances are computed when method is skin. + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml new file mode 100644 index 000000000..615b3b76a --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml @@ -0,0 +1,348 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Configuration of a paraprobe-intersector tool run in atom probe microscopy. + + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + ISO 8601 formatted time code with local time zone offset to + UTC information included when this configuration file was created. + + + + + For now a support field for the tool to identify how many individual + analyses the tool should execute as part of the analysis. + + + + + Tracking volume_volume_spatial_correlation is the process of building logical + relations between volumetric features based on meshes, their proximity and + eventual intersections. Volumetric overlap and proximity of volumetric + features is identified for members of sets of features to members of + other sets of volumetric features. + Specifically, for each time step k pairs of sets are compared: + Members of a so-called current_set to members of a so-called next_set. + Members can be different types of volumetric features. + In the analysis of M. Kuehbach et al. specifically features can be + so-called objects (closed non-degnerated polyhedra representing watertight + parts of an e.g. iso-surface) and/or proxies. Proxies are computed + doppelganger/replacement meshes for parts of an iso-surface which initially + were not resulting in watertight meshes because objects at the edge + of the dataset or incompletely measured or truncated objects. + + + + Specifies the method whereby to decide if two objects intersect volumetrically. + For reasons which are detailed in the supplementary material of + `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, the tool by + default assumes that two objects intersect if they share at least one + ion with the same evaporation ID (shared_ion). + Alternatively, with specifying tetrahedra_intersections, + the tool can perform an intersection analysis which attempts to + tetrahedralize first each polyhedron. If successful, the tool then checks + for at least one pair of intersecting tetrahedra to identify if two objects + intersect or not. + + However, we found that these geometrical analyses can result in corner + cases which the currently used library (TetGen) was not unable to + tetrahedralize successfully. These cases were virtually always + associated with complicated non-convex polyhedra which had portions + of the mesh that were connected by almost point like tubes of triangles. + Finding more robust methods for computing intersections between + not necessarily convex polyhedra might improve the situation in the future. + + + + + + + + Specifies if the tool evaluates if for each pair the two objects + (and proxies if used) intersect volumetrically. + + + + + Specifies if the tool evaluates if for each pair the two objects + (and proxies if used) lie closer to one another than the + threshold_proximity. + + + + + Specifies if the tool evaluates, ones all tracking tasks were + successfully completed, how intersecting or proximity related + objects build sub-graphs. This is the feature which enabled + M. Kühbach et al. 2022 the high-throughput analyses of how many + objects are coprecipitates in the sense that they are single, + duplet, triplet, or high-order. For these analyses to work + has_object_volume needs to be activated. + + + + + The maximum Euclidean distance between two objects below which + both objects are still considered within proximity. + + + + + + Specifies if the tool stores the so-called forward relations between + nodes representing members of the current_set to nodes representing + members of the next_set. + + + + + Specifies if the tool stores the so-called backward relations between + nodes representing members of the next_set to nodes representing + members of the current_set. + + + + + Current set stores a set of members, meshes of volumetric features, + which will be checked for proximity and/or volumetric intersection, + to members of the current_set. + The meshes were generated as a result of some other meshing process. + + + + This identifier can be used to label the current set. The label + effectively represents (can be interpreted as) the time/iteration + step when the current set was taken. As it is detailed in `M. Kühbach + et al. 2022 <https://arxiv.org/abs/2205.13510>`_, this identifier + takes the role of the time variable :math:`k`. + + + + + + The total number of distinguished feature sets FEATURE. + It is assumed that the members within all these FEATURE sets + are representing a set together. As an example this set might represent + all volumetric_features. However, users might have formed + a subset of this set where individuals were regrouped. + For paraprobe-nanochem this is the case for objects and proxies. + Specifically, objects are distinguished further into those far + from and those close to the edge of the dataset. + Similarly, proxies are distinguished further into those far + from and those close to the edge of the dataset. + So while these four sub-sets contain different so-called types of + features key is that they were all generated for one set, here the + current_set. + + + + + + Descriptive category explaining what these features are. + + + + + + + + + + + Name of the (NeXus)/HDF5 file which contains triangulated + surface meshes of the members of the set as instances of + NXcg_polyhedron_set. + + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + String whereby the path to the geometry data can be interferred automatically. + Currently groupname_geometry_prefix/object<ID>/polyhedron. + + + + + Array of identifier whereby the path to the geometry data + can be interferred automatically. + + + + + + + + + + Next set stores a set of members, meshes of volumetric features, + which will be checked for proximity and/or volumetric intersection, + to members of the next_set. + The meshes were generated as a result of some other meshing process. + + + + This identifier can be used to label the next_set. The label + effectively represents (can be interpreted as) the time/iteration + step when the current set was taken. As it is detailed in `M. Kühbach + et al. 2022 <https://arxiv.org/abs/2205.13510>`_, this identifier + takes the role of the time variable :math:`k + 1`. + + + + + + The total number of distinguished feature sets FEATURE. + It is assumed that the members within all these FEATURE sets + are representing a set together. As an example this set might represent + all volumetric_features. However, users might have formed + a subset of this set where individuals were regrouped. + For paraprobe-nanochem this is the case for objects and proxies. + Specifically, objects are distinguished further into those far + from and those close to the edge of the dataset. + Similarly, proxies are distinguished further into those far + from and those close to the edge of the dataset. + So while these four sub-sets contain different so-called types of + features key is that they were all generated for one set, here the + next_set. + + + + + + Descriptive category explaining what these features are. + + + + + + + + + + + Name of the (NeXus)/HDF5 file which contains triangulated + surface meshes of the members of the set as instances of + NXcg_polyhedron_set. + + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + String whereby the path to the geometry data can be interferred automatically. + Currently groupname_geometry_prefix/object<ID>/polyhedron. + + + + + Array of identifier whereby the path to the geometry data + can be interferred automatically. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml new file mode 100644 index 000000000..ab98e2e98 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml @@ -0,0 +1,1114 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + How many iontypes does the delocalization filter specify. + + + + + How many disjoint control points are defined. + + + + + How many iontypes does the interface meshing iontype filter specify. + + + + + How many DCOM iterations. + + + + + Maximum number of atoms per molecular ion. + + + + + Configuration of a paraprobe-nanochem tool run in atom probe microscopy. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + ISO 8601 formatted time code with local time zone offset to + UTC information included when this configuration file was created. + + + + + How many individual analyses should the tool execute as part of the analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The tool enables to inject a previously computed triangle soup or + triangulated surface mesh representing a model (of the surface) of + the edge of the dataset. This model can be used to detect and control + various sources of bias in the analyses. + + + + + Name of the HDF5 file which contains vertex coordinates and facet + indices to describe the desired set of triangles which represents + the edge of the dataset. + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + Absolute path to the HDF5 dataset in the respectively specified HDF5 + file under filename which details the array of vertex positions. + + + + + Absolute path to the HDF5 dataset in the respective specified HDF5 + file under filename which details the array of facet indices. + + + + + + The tool enables to inject precomputed distance information for each + point/ion which can be used for further post-processing and analysis. + + + + + Name of an HDF5 file which contains the ion distances. + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + Absolute HDF5 path to the dataset with distance values for each ion. + + + + + + + + Discretization of the ion point cloud on a three-dimensional grid. + + + + Delocalization in the field of atom probe microscopy is the process + of discretizing a point cloud. By default the tool computes a full + kernel density estimation of decomposed ions to create one discretized + field for each element. + + Although, this uses an efficient multithreaded algorithm, + the computation is costly. Therefore, it can be advantageous for users + to load an already computed delocalization. This can be achieved with + the load_existent option. + When using this option the user is responsible to assure that the + settings which were used for computing this already existent delocalization + are specified in the same manner as they were. + + + + + + + + + + + Matrix of isotope vectors representing iontypes. + The filter specifies a matrix of isotope_vectors which is the most + general approach to define if and how many times an ion is counted. + Currently, paraprobe_nanochem performs a so-called atomic decomposition + of all iontypes. Specifically, the tool interprets of how many + elements/atoms a molecular ion is composed; and thus determines the + atoms multiplicity with respect to the iontype. + + Let's take the hydroxonium H3O+ molecular ion as an example: + It contains hydrogen and oxygen as atoms. The multiplicity of hydrogen + is three whereas that of oxygen is one. Therefore in an atomic + decomposition computation of the iso-surface each H3O+ ion adds + three hydrogen counts. This is a practical solution which accepts + the situation that during an atom probe experiment not each bond + of each ion/a group of neighboring atoms is broken but molecular + ions get detected. The exact ab-initio details depend on the local + field conditions and thus also the detailed spatial arrangement + of the atoms and their own electronic state and that of the neighbors + before and upon launch. + Being able to measure the information for such sites only as + molecular ions causes an inherent information loss with respect to the + detailed spatial arrangement. This information loss is more relevant + for local electrode atom probe than for field ion microscopy setting + how precisely the atomic positions can be reconstructed. + Accounting for multiplicities assures that at least the + compositional information is analyzed. + + + + + + + + + List of individual grid resolutions to analyse. + Paraprobe discretizes on a cuboidal 3D grid with cubic cells, with + an edge length of values in gridresolutions. + + + + + + Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of voxel + beyond which the Gaussian Ansatz function will be truncated. + Intensity beyond the kernel is refactored into the kernel via + a normalization procedure. + + + + + Variance of the Gaussian Ansatz kernel :math:`\sigma_x = \sigma_y = 2 \cdot + \sigma_z`. + + + + + + How should the results of the kernel-density estimation be computed + into quantities. By default the tool computes the total number + (intensity) of ions or elements. Alternatively the tool can compute + the total intensity, the composition, or the concentration of the + ions/elements specified by the white list of elements in each voxel. + + + + + + + + + + + Specifies if the tool should report the delocalization 3D field values. + + + + + + + Optional computation of iso-surfaces after each computed delocalization + to identify for instance objects in the microstructure + (line features, interfaces, precipitates). + + + + As it is detailed in M. Kühbach et al. 2022 npj Comp. Mat., + the handling of triangles at the edge of the dataset requires + special attention. Especially for composition-normalized + delocalization it is possible that the composition increases + towards the edge of the dataset because the quotient of two numbers + which are both smaller than one is larger instead of smaller than + the counter. By default, the tool uses a modified marching cubes + algorithm of Lewiner et al. which detects if voxels face such a + situation. In this case, no triangles are generated for such voxels. + Alternatively, (via setting keep_edge_triangles) the user can + instruct the tool to not remove these triangles at the cost of bias. + + Specifically, in this case the user should understand that all + objects/microstructural features in contact with the edge of the + dataset get usually artificial enlarged and their surface mesh + often closed during the marching. This closure however is artificial! + It can result in biased shape analyses for those objects. + The reason why this should in general be avoided is a similar + argument as when one analyzes grain shapes in orientation microscopy + via e.g. SEM/EBSD. Namely, these grains, here the objects at the + edge of the dataset, were not fully captured during e.g. limited + field of view. + Therefore, it is questionable if one would like to make + substantiated quantitative statements about them. + + Thanks to collaboration with the V. V. Rielli and S. Primig, though, + paraprobe-nanochem implements a complete pipeline to + process even these objects at the edge of the dataset. Specifically, + the objects are replaced by so-called proxies, i.e. replacement + objects whose holes on the surface mesh have been closed if possible + via iterative mesh and hole-filling procedures with fairing operations. + In the results of each paraprobe-nanochem run, these proxy objects + are listed separately to allow users to quantify and analyze in + detail the differences when accounting for these objects or not. + Especially this is relevant in atom probe microscopy as objects + can contain a few dozen atoms only. + Users should be aware that results from fairing operations should + be compared to results from analyses where all objects at the edge + of the dataset have been removed. + + Also users should be careful with overestimating the statistical + significance of their dataset especially when using atom probe + to compare multiple descriptors: Even though a dataset may give + statistically significant results for compositions, this does not + necessarily mean it will yield also statistically significant + and unbiased results for three-dimensional object analyses. + Being able to quantify these effects and making atom probers + aware of these subtleties was one of the main reasons why the + paraprobe-nanochem tool was implemented. + + + + + + + + + The ion-to-edge-distance that is used in the analyses of objects + (and proxies) to identify whether these are inside the dataset or + close to the edge of the dataset. If an object has at least one ion + with an ion-to-edge-distance below this threshold, the object is + considered as one which lies close to the edge of the dataset. + This implements essentially a distance-based approach to solve + the in general complicated and involved treatment of computing + volumetric intersections between not-necessarily convex + closed 2-manifolds. In fact, such computational geometry analyses + can face numerical robustness issues as a consequence of which a + mesh can be detected as lying completely inside a dataset although + in reality it is epsilon-close only, i.e. almost touching only + the edge (e.g. from inside). + Practically, humans would state in such case that the object is + close to the edge of the dataset; however mathematically the object + is indeed completely inside. + In short, a distance-based approach is rigorous and more flexible. + + + + + + Array of iso-contour values. For each value the tool computes + an iso-surface and performs subsequent analyses. + The unit depends on the choice for the normalization of the + accumulated ion intensity values per voxel: + + * total, total number of ions, irrespective their iontype + * candidates, total number of ions with type in the isotope_whitelist. + * composition, candidates but normalized by composition, i.e. at.-% + * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 + + + + + + Specifies if the tool should report the triangle soup which represents + each triangle of the iso-surface complex. + Each triangle is reported with an ID specifying to which triangle + cluster (with IDs starting at zero) the triangle belongs. + The clustering is performed with a modified DBScan algorithm. + + + + + Specifies if the tool should analyze for each cluster of triangles + how they can be combinatorially processed to describe a closed + polyhedron. Such a closed polyhedron (not-necessarily convex!) + can be used to describe objects with relevance in the microstructure. + Users should be aware that the resulting mesh does not necessarily + represent the original precipitate. In fact, inaccuracies in the + reconstructed positions cause inaccuracies in all downstream + processing operations. Especially the effect on one-dimensional + spatial statistics like nearest neighbor correlation functions these + effects were discussed in the literature + `B. Gault et al. <https://doi.org/10.1017/S1431927621012952>`_ + In continuation of these thoughts this applies also to reconstructed + objects. A well-known example is the discussion of shape deviations + of Al3Sc precipitates in aluminium alloys which in reconstructions + can appear as ellipsoids although they should be almost spherical, + depending on their size. + + + + + Specifies if the tool should report a triangulated surface mesh + for each identified closed polyhedron. It is common that a + marching cubes algorithm creates iso-surfaces with a fraction of very + small sub-complexes (e.g. small isolated tetrahedra). + + These can be for instance be small tetrahedra/polyhedra about the + center of a voxel of the support grid on which marching cubes operates. + When these objects are small, it is possible that they contain no ion; + especially when considering that delocalization procedures smoothen + the positions of the ions. Although these small objects are interesting + from a numerical point of view, scientists may argue they are not worth + to be reported: + Physically a microstructural feature should contain at least a few + atoms to become relevant. Therefore, paraprobe-nanochem by default + does not report closed objects which bound not at least one ion. + + + + + Specifies if the tool should report properties of each closed + polyhedron, such as volume and other details. + + + + + Specifies if the tool should report for each closed polyhedron an + approximately optimal bounding box fitted to all triangles of the + surface mesh of the object and ion positions inside or on the + surface of the mesh. + This bounding box informs about the closed object's shape + (aspect ratios). + + + + + + Specifies if the tool should report for each closed polyhedron + all evaporation IDs of those ions which lie inside or on the + boundary of the polyhedron. This information can be used e.g. + in the paraprobe-intersector tool to infer if two objects share + common ions, which can be interpreted as an argument to assume + that the two objects intersect. + + Users should be aware that two arbitrarily closed polyhedra + in three-dimensional space can intersect but not share a common ion. + In fact, the volume bounded by the polyhedron has sharp edges. + When taking two objects, an edge of one object may for instance + pierce into the surface of another object. In this case the + objects partially overlap / intersect volumetrically; + however this piercing might be so small or happening in the volume + between two ion positions and thus sharing ions is a sufficient + but not a necessary condition for object intersections. + + Paraprobe-intersector implements a rigorous alternative to handle + such intersections using a tetrahedralization of closed objects. + However, in many practical cases, we found through examples that there + are polyhedra (especially when they are non-convex and have almost + point-like) connected channels, where tetrahedralization libraries + have challenges dealing with. In this case checking intersections + via shared_ions is a more practical alternative. + + + + + Specifies if the tool should report if a (closed) object has + contact with the edge of the dataset. For this the tool currently + inspects if the shortest distance between the set of triangles of the + surface mesh and the triangles of the edge model is larger than the + edge_threshold. If this is the case, the object is assumed to be + deeply embedded in the interior of the dataset. Otherwise, the object + is considered to have an edge contact, i.e. it is likely affected + by the fact that the dataset is finite. + + + + + + Specifies if the tool should analyze a doppelganger/proxy mesh for + each cluster of triangles whose combinatorial analysis according + to has_object showed that the object is not a closed polyhedron. + Such proxies are closed via iterative hole-filling, mesh refinement, + and fairing operations. + Users should be aware that the resulting mesh does not necessarily + represent the original precipitate. In most cases objects, + like precipitates in atom probe end up as open objects because + they have been clipped by the edge of the dataset. Using a proxy is + then a strategy to still be able to account for these objects. + Nevertheless users should make themselves familiar with the + potential consequences and biases which this can introduce + into the analysis. + + + + + Like has_object_geometry but for the proxies. + + + + + Like has_object_properties but for the proxies. + + + + + Like has_object_obb but for the proxies. + + + + + Like has_object_ions but for the proxies. + + + + + Like has_object_edge_contact but for the proxies. + + + + + Specifies if the tool should report for each closed object a + (cylindrical) region of interest placed, centered, and align + with the local normal for each triangle of the object. + + + + + Specifies if the tool should report for each ROI that was placed + at a triangle of each object if this ROI intersects the edge of + the dataset. Currently paraprobe-nanochem supports cylindrical + ROIs. A possible intersection of these with the edge of the + dataset, i.e. the triangulated surface mesh model for the edge + is performed. This test checks if the cylinder intersects with + a triangle of the surface mesh. If this is the case, the ROI is + assumed to make edge contact, else, the ROI is assumed to have + no edge contact. + + This approach does not work if the ROI would be completely + outside the dataset. Also in this case there would be + no intersection. For atom probe this case is practically + irrelevant because for such a ROI there would also be no ion + laying inside the ROI. Clearly it has thus to be assumed that + the edge model culls the entire dataset. Instead, if one would + cut a portion of the dataset, compute an edge model for this + point cloud, it might make sense to place a ROI but in this + case the edge contact detection is not expected to work properly. + + + + + + + Analyses of interfacial excess. + + + + Interfacial excess computations are performed for local regions-of-interests + (ROIs) at selected facets or interface patch. + For instance many scientist compute the interfacial excess for + selected triangle facets of a created iso-surface. In this case, + computed iso-surfaces of paraprobe could be used. An example are triangle + facet sets about closed polyhedra, for instance to compute interfacial + excess related to phase boundaries of second-phase precipitates. + + Another example are free-standing triangle patches of the iso- + surfaces which paraprobe creates. These could be characterized + for interfacial excess. The sub-routines during iso-surface + computations already include a procedure to automatically align + local triangle normals based on the gradients of e.g. composition + fields. In this case, these triangulated surface patches + could also be used as a source for computing interfacial + excess. + + Often scientists face situations, though, in which there is no + immediately evident composition gradient across the interface + (grain or phase boundary) and orientation information about the + adjoining crystal is neither available nor reliable enough. + + In this case `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_ proposed a method + to manually place control points and run an automated tessellation-based + algorithm to create a triangulated surface patch, i.e. a model of the + location of the interface. In a post-processing step this triangle + set can then be used to compute again interfacial excess in an + automated manner by placing ROIs and aligning them with + consistently precomputed triangle normals. + + A similar use case is conceptually the one proposed by `X. Zhou et al. <https://doi.org/10.1016/j.actamat.2022.117633>`_ + They used first a deep-learning method to locate planar triangulated + grain boundary patches. These are eventually processed further + with manual editing of the mesh via tools like Blender. + Once the user is satisfied with the mesh, the computations of interfacial + excess reduce again to an automated placing of ROIs, computations + of the distributing of ions to respective ROIs and + reporting the findings via plotting. + + Yet another approach for constructing an triangulated surface patch + of an interface is to use point cloud processing methods which have + been proposed in the laser-scanning, geoinformatics, and CAD community. + Different computational geometry methods are available for fitting + a parameterized surface to a set of points, using e.g. non-uniform + rational B-splines (NURBS) and triangulating these according + to prescribed mesh quality demands. + + The advantage of these methods is that they can be automated and + pick up curved interface segments. The disadvantage is their often + strong sensitivity to parameterization. As a result also such methods + can be post-processed to yield a triangulated surface patch, + and thus enable to run again automated ROI placement methods. + For example like these which were explored for the use case of + iso-surfaces with closed objects and free-standing + surface patches that delineate regions of the dataset with a + pronounced composition gradient normal to the interface. + + This summary of the situations which atom probers can face when + requesting for interfacial excess computations, substantiates there + exists a common set of settings which can describe all of these methods + and, specifically, as here exemplified, the automated placing + and alignment functionalities for ROIs that is an important + step all these workflows. + + Specifically, paraprobe-nanochem operates on an already existent + triangle set. + + + + + + + + + + The interface model is the result of a previous (set of) processing + steps as a result of which the user has created a triangulated + surface mesh (or a set of, eventually connected such meshes). + These interface models are useful, if not required, in cases when + there is no other independent approach to locate an interface. + + These are cases when insufficient crystallographic latent + information is available and also no consistent concentration + gradient detectable across the interface. It is then the users' + responsibility to deliver a triangle mesh of the interface model. + + + + Filename to HDF5 file which contain vertex coordinates, facet indices, + facet unit normals. The user is responsible for the triangle + and winding order to be consistent. + Input is expected as a matrix of the coordinates for all disjoint + vertices, a (Nvertices, 3)-shaped array of NX_FLOAT. + Input is expected to include also a matrix of facet indices + referring to these disjoint vertices. This matrix should be a + (Nfacets, 3)-shaped array of NX_UINT. Further required input + is a (Nfacets, 3)-shaped array of NX_FLOAT signed facet unit + normals and a (Nvertices, 3)-shaped array of NX_FLOAT signed + vertex unit normals. Vertex indices need to start at zero and + must not exceed Nvertices - 1, i.e. the identifier_offset is 0 + and facet indices are indexed implicitly, i.e. [0, Nvertices-1]. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically + contains these data. + + + + + + Absolute HDF5 path to the dataset which specifies the + array of vertex positions. + + + + + Absolute HDF5 path to the dataset which specifies the + array of facet indices. + + + + + Absolute HDF5 path to the dataset which specifies the + array of facet signed unit normals. + + + + + Absolute HDF5 path to the dataset which specifies the + array of vertex signed unit normals. + + Users should be aware that triangulated surface meshes are + only approximations to a given complex, eventually curved shape. + Consequently, computations of normals show differences between + the vertex and facet normals. Vertex normals have to be + interpolated from normals of neighboring facets. Consequently, + these normals are affected by the underlying parameterization + and curvature estimation algorithms, irrespective of how + contributions from neighboring facets are weighted. By contrast, + facet normals are clearly defined by the associated triangle. + Their disadvantage is that they the normal field has discontinuities + at the edges. In general the coarser an object is triangulated + the more significant the difference becomes between computations + based on facet or vertex normals. + Paraprobe-nanochem works with facet normals as it can use + parts of the numerical performance gained by using cutting + edge libraries to work rather with finer meshes. + + + + + + + + Create a simple principle component analysis (PCA) to mesh a + free-standing interface patch through a point cloud of decorating solutes. + These models can be useful for quantification of Gibbsian + interfacial excess for interfaces where iso-surface based methods + may fail or closed objects from iso-surfaces are not desired or + when e.g. there are no substantial or consistently oriented + concentration gradients across the interface patch. + + The interface_meshing functionality of paraprobe-nanochem can be useful + when there is also insufficient latent crystallographic information + available that could otherwise support modelling the interface, + via e.g. ion density traces in field-desorption maps, as were used and + discussed by `Y. Wei et al. <https://doi.org/10.1371/journal.pone.0225041>`_ + or are discussed by `A. Breen et al. <https://github.com/breen-aj/detector>`_ + + It is noteworthy that the method here used is conceptually very similar + in implementation to the work by `Z. Peng et al. <https://doi.org/10.1017/S1431927618016112>`_ + Noteworthy, her team uses the DCOM approach originally proposed by P. Felfer et al. + However, both of these previous works neither discuss in detail + nor implement inspection functionalities which enable a detection of + potential geometric inconsistencies or self-interactions of the + resulting DCOM mesh. This is what paraprobe-nanochem implements + via the Computational Geometry Algorithms Library. + + + + Method how to initialize the PCA: + + * default, means based on segregated solutes in the ROI + * control_point_file, means based on reading an external list of + control points, currently coming from the Leoben APT_Analyzer. + + The control_point_file is currently expected with a specific format. + The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. <https://github.com/areichm/APT_analyzer>`_ + to create a control_point_file which can be parsed by paraprobe-parmsetup + to match the here required formatting in control_points. + + + + + + + + + The name of the control point file to use. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically + contains these data. + + + + + + X, Y, Z coordinates of disjoint control point read from + an HDF5 file named according to control_point_file. + + + + + + + + + + Method used for identifying and refining the location of the + interface. Currently, paraprobe-nanochem implements a PCA followed + by an iterative loop of isotropic mesh refinement and DCOM step(s), + paired with self-intersection detection in a more robust + implementation. + + + + + + + + Specify the types of those ions which decorate the interface and + can thus be assumed as markers for locating the interface and + refining its local curvature. + + + + Array of iontypes to filter. The list is interpreted as a whitelist, + i.e. ions of these types are considered the decorating species (solutes). + + + + + + + + + How many times should the DCOM and mesh refinement be applied? + + + + + Array of decreasing positive not smaller than one nanometer real values + which specify how the initial triangles of the mesh should be iteratively + refined by edge splitting and related mesh refinement operations. + + + + + + + + + Array of decreasing positive not smaller than one nanometer real values + which specify the radius of the spherical region of interest within + which the DCOM algorithm decides for each vertex how the vertex will + be eventually relocated. The larger the DCOM radius is relative to + the target_edge_length the more likely it is that vertices will be + relocated so substantially that eventually triangle self-intersections + can occur. If the code detects these it warns and stops in a + controlled manner so that the user can repeat the analyses + with a smaller value. + + + + + + + + + Array of integers which specify for each DCOM step how many times + the mesh should be iteratively smoothened. + + Users should be aware the three array target_edge_length, + target_dcom_radius, and target_smoothing_step are interpreted in the + same sequence, i.e. the zeroth entry of each array specifies the + values to be used in the first DCOM iteration. The first entry of + each array those for the second DCOM iteration and so on and so forth. + + + + + + + + + Functionalities for placing regions-of-interest (ROIs) in the dataset + or at specific microstructural features to characterize composition + profiles and cumulated profiles for quantification of interfacial excess. + Paraprobe-nanochem currently places cylindrical ROIs. ROIs are probed + across the triangulated surface of a user-defined mesh. + ROIs are placed at the barycenter of the triangular facet. + + The tool can be instructed to orient the profile for each ROIs with + the positive normal of the triangle facet normals. Profiles are + computed for each ROI and facet triangle. The code will test which + ROIs are completely embedded in the dataset. + Specifically, in this test the tool evaluates if the ROI cuts at least + one triangle of the triangulated surface mesh of the edge of the dataset. + If this is the case the ROI will be considered close to the edge + (of the dataset) and not analyzed further; else the ROI will be + processed further. + Users should be aware that the latter intersection analysis is strictly + speaking not a volumetric intersection analysis as such one is much + more involved because the edge model can be a closed non-convex polyhedron + in which case one would have to test robustly if the cylinder pierces + or is laying completely inside the polyhedron. For this the polyhedron has + to be tessellated into convex polyhedra as otherwise tests like the + Gilbert-Johnson-Keerthi algorithm would not be applicable. + + Specifically, the tool computes atomically decomposed profiles. + This means molecular ions are split into atoms/isotopes with respective + multiplicity. As an example an H3O+ molecular ion contains three + hydrogen and one oxygen atom respectively. The tool then evaluates + how many ions are located inside the ROI or on the surface of the + ROI respectively. All atom types and the unranged ions are distinguished. + As a result, the analyses yield for each ROI a set of sorted lists of + signed distance values. Currently, the distance is the projected + distance of the ion position to the barycenter of the triangle + and triangle plane. + + This will return a one-dimensional profile. Post-processing the set + of atom-type-specific profiles into cumulated profiles enable the + classical Krakauer/Seidman-style interfacial excess analyses. + Furthermore, the tool can be instructed to compute for each + (or a selected sub-set of facet) a set of differently oriented profiles. + + + + + The feature mesh enables the injection of previously computed triangle + soup or mesh data. Such a mesh can be the model for a grain- or phase + boundary patch (from e.g. interface_meshing) jobs. + + + + Name of the HDF5 file which contains vertex coordinates and facet + indices to describe the desired set of triangles which represents + the feature. + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + Absolute path to the HDF5 dataset in the respectively specified HDF5 + file under filename which details the array of vertex positions. + + + + + Absolute path to the HDF5 dataset in the respective specified HDF5 + file under filename which details the array of facet indices. + + + + + Absolute path to the HDF5 dataset in the respective specified HDF5 + file under filename which details consistently oriented facet + normals of the facets. + + + + + + + + + + + The tool enables to inject precomputed distance information for each + point which can be used for further post-processing and analysis. + + + + + Name of an HDF5 file which contains ion distances. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically contains + these data. + + + + + + Absolute HDF5 path to the dataset with distance values for each ion. + + + + + + Which type of distance should be reported for the profile. + + + + + + + + + In which directions should the tool probe for each ROI. + + + + + + + + + For each ROI, how high (projected on the cylinder axis) + should the cylindrical ROI be. + + + + + + For each ROI, how wide (radius) should the cylindrical ROI be. + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml new file mode 100644 index 000000000..f832bf02b --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml @@ -0,0 +1,297 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The number of isotopes to consider as building blocks for searching molecular + ions. + + + + + The number of compositions to consider for molecular ion search tasks. + + + + + Configuration of a paraprobe-ranger tool run in atom probe microscopy. + + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + How many task to perform? + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A list of pairs of number of protons and either the value 0 (per row) + or the mass number for all those isotopes which are assumed present + in a virtual specimen. + The purpose of this field is to compute also composition-weighted + products to yield a simple estimation which could potentially help + scientists to judge if certain molecular ions are to be expected. + The corresponding setting store_composition_weighted_product should be + activated. + + + + + + + + + + A list of pairs of number of protons and mass number for all isotopes + to consider that can be composed into (molecular) ions, during the + recursive molecular_ion_search. + + + + + + + + + The mass-to-charge-state ratio interval in which + all molecular ions are searched. + + + + + + + + The maximum charge that a molecular ion should have. + + + + + The maximum number of isotopes of which the molecular ion + should be composed. Currently this must not be larger than 32. + + Users should be warned that the larger the maximum_charge and + especially the larger the maximum_number_of_isotopes is chosen, + the eventually orders of magnitude more costly the search becomes. + + This is because paraprobe-ranger computes really all (at least) + theoretically possible combinations that would have likely a + mass-to-charge-state ratio in the specified mass_to_charge_interval. + It is the challenge in atom probe to judge which of these (molecular) + ions are feasible and also practically possible. This tool does not + answer this question. + + Namely, which specific molecular ion will evaporate, remain stable + during flight and becomes detected is a complicated and in many cases + not yet in detail understood phenomenon. The ab-initio conditions + before and during launch, the local environment, arrangement and field + as well as the flight phase in an evacuated but not analysis chamber + with a complex electrical field, eventual laser pulsing in place, + temperature and remaining atoms or molecules all can have an effect + which iontypes are really physically evaporating and detected. + + + + + Report the accumulated atomic mass from each isotope building the ion. + Accounts for each identified ion. + Relatistic effects are not accounted for. + + + + + Report the product of the natural abundances from each isotope building + the ion. Accounts for each identified ion. + + The value zero indicates it is not possible to build such molecular ion + from nuclids which are all observationally stable. + Very small values can give an idea/about how likely such a molecular ion + is expected to form assuming equal probabilities. + + However in atom probe experiments this product has to be modified + by the (spatially-correlated) local composition in the region from + which the ions launch because the formation of a molecular ion depends + as summarized under maximum_number_of_isotopes on the specific + quantum-mechanical configuration and field state upon launch + or/and (early state) of flight respectively. + We are aware that this modified product can have a substantially + different value than the natural_abundance_product. + + Natural abundancies folded with the estimated compositions of the + specimen can differ by orders of magnitude. + + + + + + Report the charge state of the ions. + + + + + Report if identified ions should be characterized + wrt to their number of disjoint isotopes. + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml new file mode 100644 index 000000000..1293fb98d --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml @@ -0,0 +1,142 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Configuration of a paraprobe-selector tool run in atom probe microscopy. + + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + How many roi_selection processes should the tool execute. + + + + + This process identifies which of the points/ions in the datasets are + inside or on the surface of geometric primitives and meet optionally + specific other filtering constraints. + A typical use case of a roi_selection is to restrict analyses to + specific regions of the dataset, eventually regions with a complicated + shape. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml new file mode 100644 index 000000000..d886dc0da --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml @@ -0,0 +1,374 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms per molecular ion. Should be 32 for paraprobe. + + + + + Number of different sources iontypes to distinguish. + + + + + Number of different target iontypes to distinguish. + + + + + Configuration of a paraprobe-spatstat tool run in atom probe microscopy. + + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + How many range_with_existent_iontypes processes should + the tool execute as part of the analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The tool enables to inject precomputed distances of each ion to a + representation of the edge of the dataset which can be used to + control and substantially reduce edge effects when computing + spatial statistics. + + + + Name of an HDF5 file which contains ion-to-edge distances. + + + + + Absolute HDF5 path to the dataset with the + ion-to-edge distance values for each ion. + The shape of the distance values has to match the length + of the ion positions array in dataset/dataset_name_reconstruction + and dataset_name_mass_to_charge respectively. + + + + + Threshold to define how large an ion has to lay at least far away + from the edge of the dataset so that the ion can act as a source, + i.e. that an ROI is placed at the location of the ion and its + neighbors are analyzed how they contribute to the computed statistics. + + The ion_to_edge_distances threshold can be combined with a threshold + for the ion_to_feature_distances. + Specifically, if ion_to_feature_distances are loaded an ion only + acts as a source if both threshold criteria are met. + + The threshold is useful to process the dataset such that ROIs do + not protrude out of the dataset as this would add bias. + + + + + + In addition to spatial filtering, and considering how far ions lie + to the edge of the dataset, it is possible to restrict the analyses + to a sub-set of ions within a distance not farther away to a feature than + a threshold value. + + + + Name of an HDF5 file which contains ion-to-feature distances. + + + + + Absolute HDF5 path to the dataset with the + ion-to-feature distance values for each ion. + + + + + Threshold to define how close an ion has to lay to a feature so that + the ion can at all qualify as a source, i.e. that an ROI is placed + at the location of the ion and its neighbors are then analyzed + how they contribute to the computed statistics. + + Recall that the ion_to_feature_distances threshold is combined + with the ion_to_edge_distances threshold. + + + + + + + Specifies if the iontypes are randomized for the point cloud or not. + Internally paraprobe uses a sequentially executed deterministic MT19987 + (MersenneTwister) pseudo-random number generator to shuffle the + iontype labels randomly across the entire set of ions. + + + + + + + + + + How should the iontype be interpreted on the source-side, i.e. + all these ion positions where a regions-of-interest (ROI) around + so-called source ions will be placed. Different options exist + how iontypes are interpreted given an iontype represents + in general a (molecular) ion with different isotopes that have + individually different multiplicity. + + The value resolve_all will set an ion active in the analysis regardless + of which iontype it is. Each active ion is accounted for once. + + The value resolve_unknown will set an ion active when the ion is + of the UNKNOWNTYPE type. Each active ion is accounted for once. + + The value resolve_ion will set an ion active if it is of the specific + iontype, irregardless of its elemental or isotopic details. + Each active ion is counted once. + + The value resolve_element will set an ion active, and most importantly, + account for each as many times as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + + The value resolve_isotope will set an ion active, and most importantly, + account for each as many times as the (molecular) ion contains + isotopes in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized, i.e. how + often it is accounted for. + + + + + + + + + + + + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. + + + + + + + + + Similarly as ion_query_type_source how should iontypes be interpreted + on the target-side, i.e. how many counts will be bookkept for ions + which are neighbors of source ions within or on the surface of each + inspection/ROI about each source ion. + Source ion in the center of the ROI are not accounted for during + counting the summary statistics. + For details about the resolve values consider the explanations in + ion_query_type_source. These account for ion_query_type_target as well. + + + + + + + + + + + + + Matrix of isotope vectors, as many as rows as different candidates for + iontypes to distinguish as possible targets. See additional comments + under ion_query_isotope_vector_source. + + + + + + + + + Specifies which spatial statistics to compute. + + + + Compute k-th nearest neighbour statistics. + + + + Order k. + + + + + Minimum value, increment, and maximum value of the histogram binning. + + + + + + + + + + Compute radial distribution function. + + + + Minimum value, increment, and maximum value of the histogram binning. + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml new file mode 100644 index 000000000..5f30cc0f2 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml @@ -0,0 +1,289 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of alpha values (and offset values) to probe. + + + + + How many different match values does the filter specify. + + + + + Configuration of a paraprobe-surfacer tool run in atom probe microscopy. + + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + For now a support field for the tool to identify how many individual + analyses the tool should executed as part of the analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specifies the method that is used to preprocess the point cloud. + The main purpose of this setting is to specify whether the point + cloud should be segmented or not during the preprocessing + to identify which points are more likely lying close to the edge + of the point cloud. These points could be more relevant than the + interior points for certain alpha-shape constructions. + + By default no such filtering is used during pre-processing. + By contrast, the option kuehbach activates a preprocessing + during which a Hoshen-Kopelman percolation analysis is used + to identify which points are closer to the edge of the dataset. + This can reduce the number of points in the alpha-shape + computation and thus improve performance substantially. + Details about the methods are reported in + `M. Kühbach et al. <https://doi.org/10.1038/s41524-020-00486-1>`_. + + + + + + + + + + When using the kuehbach preprocessing, this is the width of the + kernel for identifying which ions are in voxels close to the + edge of the point cloud. + + + + + Specifies which method to use to define the alpha value. + The value convex_hull_naive is the default. This instructs the tool + to use a fast specialized algorithm for computing only the convex + hull. The resulting triangles can be skinny. + + The value convex_hull_refine computes first also a convex_hull_naive + but refines the mesh by triangle flipping and splitting to improve + the quality of the mesh. + + The value smallest_solid instructs the CGAL library to choose a + value which realizes an alpha-shape that is the smallest solid. + + The value cgal_optimal instructs the library to choose a value + which the library considers as an optimal value. Details are + define in the respective section of the CGAL library on 3D alpha + shapes. + + The value set_of_values instructs to compute a list of + alpha-shapes for the specified alpha-values. + + The value set_of_alpha_wrappings instructs the library to generate + a set of so-called alpha wrappings. These are a method + which is similar to alpha shapes but provide additional guarantees + though such as watertightness and proximity constraints on the + resulting wrapping. + + + + + + + + + + + + + + Array of alpha values to use when alpha_value_choice is set_of_values + or when alpha_value_choice is set_of_alpha_wrappings. + + + + + + + + + Array of offset values to use when alpha_value_choice is + set_of_alpha_wrappings. The array of alpha_values and offset_values + define a sequence of (alpha and offset value). + + + + + + + + + Specifies if the tool should compute the set of exterior triangle + facets for each alpha complex (for convex hull, alpha shapes, and wrappings) + + + + + Specifies if the tool should check if the alpha complex of exterior + triangular facets is a closed polyhedron. + + + + + Specifies if the tool should compute all interior tetrahedra + of the alpha complex (currently only for alpha shapes). + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml new file mode 100644 index 000000000..ca0798c3a --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml @@ -0,0 +1,253 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Configuration of a paraprobe-tessellator tool run in atom probe microscopy. + + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + How many individual analyses should the tool execute. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The tool enables to inject precomputed distance information for + each point which can be used for further post-processing and analysis. + + + + Name of an HDF5 file which contains the ion distances. + Users are responsible this file and referred to dataset under + dataset_name have an ion_distance value for each ion. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional layer of + reproducibility. + + + + + + Absolute HDF5 path to the dataset with distance values for each ion. + + + + + + + Specifies for which points the tool will compute the tessellation. + By default, a Voronoi tessellation is computed for all ions in the + filtered point cloud. + + + + + + + + + + Specifies if the tool should report the volume of each cell. + + + + + Specifies if the tool should report the first-order neighbors of each cell. + + + + + Specifies if the tool should report the facets and vertices of each cell. + + + + + Specifies if the tool should report if the cell makes contact with + the tight axis-aligned bounding box about the point cloud. + This can be used to identify if the shape of the cell is affected + by the edge of the dataset or if cells are deeply enough embedded + into the point cloud so that the shape of their cells are not affected + by the presence of the boundary. + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml new file mode 100644 index 000000000..4d548e5bf --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml @@ -0,0 +1,119 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Configurations of a paraprobe-transcoder tool run in atom probe microscopy. + + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ideally an ever persistent resource where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result of this computational + process is recreatable deterministically. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + + + + The path and name of the file (technology partner or community format) + from which to read the reconstructed ion positions. Currently, POS, + ePOS, APT files from APSuite, and NXS, i.e. NeXus/HDF5 files + are supported. + + + + + + + + The path and name of the file (technology partner or community format + from which to read the ranging definitions, i.e. how to map mass-to- + charge-state ratios on iontypes. Currently, RRNG, RNG, and NXS, i.e. + NeXus/HDF5 files are supported. + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml deleted file mode 100644 index e7d6d7917..000000000 --- a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml +++ /dev/null @@ -1,202 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Application definition for a configuration file of the paraprobe-distancer tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specifies for which point the tool will compute distances. - - The value *default* configures that distances are computed for all points. - The value *skin* configures that distances are computed only for those - points which are not farther away located to a triangle than - threshold_distance. - - - - - - - - - Maximum distance for which distances are - computed when *method* is *skin*. - - - - - - How many triangle sets to consider. - Multiple triangle sets can be defined which are - composed into one joint triangle set for the analysis. - - - - - Each triangle_set that is referred to here should be a face_list_data_structure, - i.e. an array of (n_vertices, 3) of NX_FLOAT for vertex coordinates, an (n_facets, 3) - array of NX_UINT incident vertices of each facet. Vertex indices are assumed to - start at zero and must not exceed n_vertices - 1, i.e. the identifier_offset is 0. - Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. - - - - - - - - Absolute path in the (HDF5) file that points to the array - of vertex positions for the triangles in that triangle_set. - - - - - Absolute path in the (HDF5) file that points to the array - of vertex indices for the triangles in that triangle_set. - - - - - Absolute path in the (HDF5) file that points to the array - of vertex normal vectors for the triangles in that triangle_set. - - - - - Absolute path in the (HDF5) file that points to the array - of facet normal vectors for the triangles in that triangle_set. - - - - - Absolute path in the (HDF5) file that points to the array - of identifier for the triangles in that triangle_set. - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml deleted file mode 100644 index 011214db1..000000000 --- a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml +++ /dev/null @@ -1,202 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of points, i.e. ions in the reconstruction. - - - - - The total number of triangles in the set. - - - - - Application definition for results files of the paraprobe-distancer tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The paraprobe-distancer tool can be used for the computing of the shortest Euclidean distance for each - member of a set of points against a set of triangles. In contrast to most approaches in atom probe where the - distance is computed as the projected distance, this tool evaluates robustly the exact distance between - a point and a triangle. - - Triangles can represent for instance the facets of a triangulated surface mesh like those returned by - paraprobe-surfacer or any other set of triangles. Triangles do not have to be connected. - - Currently, paraprobe-distancer does not check if the respectively specified triangle sets are consistent, - what their topology is, or whether or not these triangles are consistently oriented. - - - - - - - - - - - - - - - - - - - - - - - - - - - The shortest analytical distance of each point to their - respectively closest triangle from the joint triangle set. - - - - - - - - For each point the identifier of the triangle for which the - shortest distance was found - - - - - - - - A support field to enable the visualization of each point - by an explicit identifier on the interval [0, n_ions - 1]. - The field can be used to visualize the points as a function - of their distance to the triangle set (e.g. via XDMF/Paraview). - - - - - - - - A bitmask that identifies which of the distance values is - assumed to have a consistent sign because the closest - triangle had a consistent outer unit normal defined. - - For points whose bit is set to 0 the distance is correct - but the sign is not reliable. - - - - Number of triangles covered by the mask. - - - - - Bitdepth of the elementary datatype that is used to store - the information content of the mask (typically 8 bit, uint8). - - - - - The content of the mask. Like for all masks used in the tools - of the paraprobe-toolbox, padding is used when number_of_objects - is not an integer multiple of bitdepth. If padding is used, - padded bits are set to 0. - - - - - - - - - A bitmask that identifies which of the triangles in the set were - considered when certain triangles have been filtered out. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml deleted file mode 100644 index efdbdf9ae..000000000 --- a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml +++ /dev/null @@ -1,278 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of entries - - - - - Application definition for a configuration file of the paraprobe-intersector tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. - - - - - - - - - - - How many v_v_spatial_correlation tasks should the tool execute. - - - - - Tracking volume_volume_spatial_correlations (v_v) is the process of building logical - relations between objects, their proximity and eventual volumetric intersections. - Here, objects are assumed to be represented as a set of triangulated surface meshes. - - Volumetric overlap and proximity of volumetric features is identified for members of - sets of features to members of other sets of volumetric features. Specifically, for each time - step :math:`k` pairs of sets are compared: - Members of a so-called current_set to members of a so-called next_set. - Members can be different types of volumetric features. - - - - - Specifies the method whereby to decide if two objects intersect volumetrically. - For reasons which are detailed in the supplementary material of `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, - it is assumed by default that two objects intersect if they share at least one ion with the same evaporation ID (shared_ion). - - Alternatively, with specifying tetrahedra_intersections, the tool can perform an intersection analysis which attempts to - tetrahedralize first each polyhedron. If successful, the tool then checks for at least one pair of intersecting tetrahedra - to identify if two objects intersect or not. However, we found that these geometrical analyses can result in corner - cases which the tetrahedralization library used in the tests (TetGen) was not unable to tetrahedralize successfully. - These cases were virtually always associated with complicated non-convex polyhedra which had portions - of the mesh that were connected by almost point like tubes of triangles. - - Finding more robust methods for computing intersections between not necessarily convex polyhedra might improve - the situation in the future. For practical reasons we have thus deactivated the functionality of tetrahedra-tetrahedron - intersections in paraprobe-intersector. - - - - - - - - Specifies if the tool evaluates if objects intersect volumetrically. - - - - - Specifies if the tool evaluates if objects lay closer to one another than - threshold_proximity. - - - - - Specifies if the tool evaluates, provided that all (preprocessing tasks were successful), how intersecting - or proximity related objects build sub-graphs. This is the feature that was used in `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_ - for the high-throughput analyses of how many objects are coprecipitates in the sense that they are single, - duplet, triplet, or high-order local groups. - - - - - - The maximum Euclidean distance between two objects below which they are - considered within proximity. - - - - - Specifies if the tool stores the so-called forward relations between nodes representing members of the - current_set to nodes representing members of the next_set. - - - - - Specifies if the tool stores the so-called backward relations between nodes representing members of the - next_set to nodes representing members of the current_set. - - - - - Current set stores a set of members, meshes of volumetric features, - which will be checked for proximity and/or volumetric intersection, - to members of the current_set. - The meshes were generated as a result of some other meshing process. - - - - This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k`) - step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). - - - - - - The total number of distinguished feature sets featureID. - It is assumed that the members within all these featureID sets - are representing a set together. As an example this set might represent - all volumetric_features. However, users might have formed - a subset of this set where individuals were regrouped. - For paraprobe-nanochem this is the case for objects and proxies. - Specifically, objects are distinguished further into those far - from and those close to the edge of the dataset. - Similarly, proxies are distinguished further into those far - from and those close to the edge of the dataset. - So while these four sub-sets contain different so-called types of - features, key is that they were all generated for one set, here the - current_set. - - - - - Name of the (NeXus)/HDF5 file which contains triangulated surface meshes of the - members of the set as instances of NXcg_polyhedron_set. - - - - Descriptive category explaining what these features are. - - - - - - - - - - - - - - - - Absolute path to the group with geometry data in the HDF5 file referred to by - path. - - - - - - Array of identifier whereby the path to the geometry data can be interferred - automatically. - - - - - - - - - - Next set stores a set of members, meshes of volumetric features, - which will be checked for proximity and/or volumetric intersection, - to members of the next_set. - The meshes were generated as a result of some other meshing process. - - - - This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k + 1`) - step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). - - - - - - The total number of distinguished feature sets featureID. - It is assumed that the members within all these featureID sets - are representing a set together. As an example this set might represent - all volumetric_features. However, users might have formed - a subset of this set where individuals were regrouped. - For paraprobe-nanochem this is the case for objects and proxies. - Specifically, objects are distinguished further into those far - from and those close to the edge of the dataset. - Similarly, proxies are distinguished further into those far - from and those close to the edge of the dataset. - So while these four sub-sets contain different so-called types of - features key is that they were all generated for one set, here the - next_set. - - - - - - Descriptive category explaining what these features are. - - - - - - - - - - - - - - - Absolute path to the group with geometry data in the HDF5 file referred to by - path. - - - - - - Array of identifier whereby the path to the geometry data can be interferred - automatically. - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml deleted file mode 100644 index 55b2aeea3..000000000 --- a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml +++ /dev/null @@ -1,274 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of links pointing from current to next. - - - - - The total number of links pointing from next to current. - - - - - The total number of members in the current_set. - - - - - The total number of members in the next_set. - - - - - The total number of cluster found for coprecipitation analysis. - - - - - The number of rows in the table/matrix for coprecipitation statistics. - - - - - Application definition for results files of the paraprobe-intersector tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - - - - - - - - - - - - The results of an overlap/intersection analysis. - - - - - A matrix of feature_identifier that specifies which named features - from the current_set have directed link(s) pointing to which named - feature(s) from the next_set. - - - - - - - - - For each link/pair in current_to_next a characterization whether the - link is due to volumetric overlap (0x00 == 0), proximity (0x01 == 1), - or something else unknown (0xFF == 255). - - - - - - - - A matrix of feature_identifier which specifies which named feature(s) - from the next_set have directed link(s) pointing to which named - feature(s) from the current_set. Only if the mapping whereby the - links are defined is symmetric it holds that next_to_current maps - the links for current_to_next in just the opposite direction. - - - - - - - - - For each link/pair in next_to_current a characterization whether the - link is due to a volumetric overlap (0x00 == 0), proximity (0x01 == 1), - or something else unknown (0xFF == 255). - - - - - - - - For each pair of links in current_to_next the volume of the - intersection, i.e. how much volume do the two features share. - If features do not intersect the volume is zero. - - - - - - - - During coprecipitation analysis the current and next set are analyzed - for links in a special way. Three set comparisons are made. Members - of the set in each comparison are analyzed for overlap and proximity: - - The first comparison is the current_set against the current_set. - The second comparison is the next_set against the next_set. - The third comparison is the current_set against the next_set. - - Once the (forward) links for these comparisons are ready, pair relations - are analyzed with respect to which objects with feature_identifier(s) - cluster in identifier space. Thereby, a logical connection (link) is - established between the features in the current_set and the next_set. - Recall that these two sets typically represent different features - within an observed system for otherwise the same parameterization. - - Examples include two sets of e.g. precipitates with differing - chemical composition that were characterized in the same material - volume representing a snapshot of an e.g. microstructure at the same - point in time. Researchers may have performed two analyses, one to - characterize precipitates A and another one for percipitates B. - - Coprecipitation analysis now logically connects these independent - characterization results to establish spatial correlations of e.g. - the precipitates' spatial arrangement. - - - - Matrix of feature_identifier and cluster_identifier pairs which - encodes the cluster to which each feature_identifier was assigned. - Here for features of the current_set. - - - - - - - - - Matrix of feature_identifier and cluster_identifier pairs which - encodes the cluster to which each feature_identifier was assigned. - Here for features of the next_set. - - - - - - - - - The identifier (names) of the cluster. - - - - - - - - Pivot table as a matrix. - The first column encodes how many members from the current_set - are in each cluster, one row per cluster. - - The second column encodes how many members from the next_set - are in each cluster, in the same row per cluster respectively. - - The third column encodes the total number of members in the cluster. - - - - - - - - - Pivot table as a matrix. - - The first column encodes the different types of - clusters based on their number of members in the sub-graph. - - The second column encodes how many clusters with - as many members exist. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml deleted file mode 100644 index 08a2b878b..000000000 --- a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml +++ /dev/null @@ -1,1040 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - How many iontypes does the delocalization filter specify. - - - - - How many grid_resolutions values. - - - - - How many kernel_variance values. - - - - - How many disjoint control points are defined. - - - - - How many iontypes does the interface meshing iontype filter specify. - - - - - How many DCOM iterations. - - - - - Maximum number of atoms per molecular ion. - - - - - Number of cylinder ROIs to place for oned_profile if no feature mesh is used. - - - - - Application definition for a configuration file of the paraprobe-nanochem tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. - - - - - - - - - - - Discretization and distributing of the ion point cloud on a 3D grid - to enable continuum-scale analyses. - - By default, the tool computes a full kernel density estimation of decomposed - ions to create one discretized field for each element. - - One delocalization task configures a parameter sweep with at least one - delocalization. The total number of runs depends on the number of - grid_resolution and kernel_variance values. For example, setting two grid_resolutions - and three kernel_variance will compute six runs. Two sets of three with the first set using - the first grid_resolutions and in sequence the kernel_variance respectively. - - - - - - - - - - - - - - - - - - - - - - A precomputed triangulated surface mesh representing a model (of the surface) - of the edge of the dataset. This model can be used to detect and control - various sources of bias in the analyses. - - - - - - - - Absolute path in the (HDF5) file that points to the array - of vertex positions for the triangles in that triangle_set. - - - - - Absolute path in the (HDF5) file that points to the array - of vertex indices for the triangles in that triangle_set. - - - - - - Distance between each ion and triangulated surface mesh. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Compute delocalization or load an existent one from input. - - - - - - - - - Serialized result of an already computed delocalization which is for performance - reasons here just loaded and not computed again. - - - - - - - - Absolute path in the (HDF5) file that points to the group within which - individual delocalization results are stored. - - - - - - - Matrix of nuclides representing how iontypes should be accounted for during - the delocalization. This is the most general approach to define if and how many - times an ion is to be counted. The tool performs a so-called atomic decomposition - of all iontypes, i.e. the tool analyses from how many atoms of each nuclide - or element respectively an (molecular) ion is built from. - - Taking the hydroxonium H3O+ molecular ion as an example: - It contains hydrogen and oxygen atoms. The multiplicity of hydrogen - is three whereas that of oxygen is one. Therefore, the respective atomic decomposition - analysis prior to the iso-surface computation adds three hydrogen counts for each - H3O+ ion. - - This is a practical solution which accepts that on the one hand not every bond is - broken during an atom probe experiment but also that ions may react further during - their flight to the detector. The exact details depend on the local field conditions, - quantum mechanics of possible electron transfer and thus the detailed trajectory - of the system and its electronic state. - - The detection of molecular ions instead of always single atom ions only is the - reason that an atom probe experiment tells much about field evaporation physics - but also faces an inherent loss of information with respect to the detailed spatial - arrangement that is independent of other imprecisions such as effect of limited - accuracy of reconstruction protocols and their parameterization. - - Unused values in each row of the matrix are nullified. - Nuclides are identified as hashed nuclide (see :ref:`NXion`) for further details. - - - - - - - - - Array of edge lengths of the cubic cells used for discretizing the reconstructed dataset - on a cuboidal 3D grid (:ref:`NXcg_grid`). The tool performs as many delocalization - computations as values are specified in grid_resolution. - - - - - - - - Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of cubic voxel - beyond which the Gaussian Ansatz function will be truncated. Intensity outside - the kernel is factorized into the kernel via a normalization procedure. - - - - - Array of variance values :math:`\sigma` of the Gaussian Ansatz kernel - (:math:`\sigma_x := \sigma`, :math:`\sigma_x = \sigma_y = 2 \cdot \sigma_z`). - The tool performs as many delocalization computations as values are specified - in kernel_variance. - - - - - - - - How should the results of the kernel-density estimation be normalized into quantities. - By default, the tool computes the total number (intensity) of ions or elements. - Alternatively, the tool can compute the total intensity, the composition, - or the concentration of the ions/elements specified by the nuclide_whitelist. - - - - - - - - - - Specifies if the tool should report the delocalization 3D field values. - - - - - Configuration of the set of iso-surfaces to compute using that delocalization. - Such iso-surfaces are the starting point for a reconstruction of so-called objects or - (microstructual) features. Examples of scientific relevant are (line features e.g. dislocations - poles, surface features such as interfaces, i.e. phase and grain boundaries, or volumetric - features such as precipitates. - Users should be aware that reconstructed datasets in atom probe are a model and may face - inaccuracies and artifacts that can be mistaken incorrectly as microstructural features. - - - - As it is detailed in `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, the handling of - triangles at the surface (edge) of the dataset requires special attention especially for - composition-normalized delocalization. Here, it is possible that the composition - increases towards the edge of the dataset because the quotient of two numbers - that are both smaller than one is larger instead of smaller than the counter. - - By default, the tool uses a modified marching cubes algorithm of Lewiner et al. - which detects if voxels face such a situation. In this case, no triangles are generated - for such voxels. - - Alternatively, keep_edge_triangles instructs the tool to not remove triangles at the - edge of the dataset at the cost of bias. When using this keep_edge_triangles users - should understand that all features in contact with the edge of the dataset get usually - artificial enlarged. Consequently, triangulated surface meshes of these objects are - closed during the marching. However, this closure is artificial and can biased shape - analyses for those objects. This also holds for such practices that are offered in - proprietary software like IVAS / AP Suite. The situation is comparable to analyses - of grain shapes via orientation microscopy from electron microscopy or X-ray - diffraction tomography. Features at the edge of the dataset may have not been - captured fully. - - Thanks to collaboration with V. V. Rielli and S. Primig from the Sydney atom probe group, - paraprobe-nanochem implements a complete pipeline to process features at the edge of the - dataset. Specifically, these are modelled and replaced with closed polyhedral objects using - an iterative mesh and hole-filling procedures with fairing operations. - - The tool bookkeeps such objects separately to lead the decision whether or not to - consider these objects to the user. Users should be aware that results from fairing operations - should be compared to results from analyses where all objects at the edge - of the dataset have been removed. Furthermore, users should be careful with overestimating - the statistical significance of their dataset especially when using atom probe when they - use their atom probe result to compare different descriptors. Even though a dataset may - deliver statistically significant results for compositions, this does not necessarily mean that - same dataset will also yield statistically significant and insignificantly biased results for - 3D object analyses! - - Being able to quantify these effects and making atom probers aware of these subtleties - was one of the main reasons why the paraprobe-nanochem tool was implemented. - - - - - - - - - The ion-to-surface distance that is used in the analyses of features to identify whether - these are laying inside the dataset or close to the surface (edge) of the dataset. - - If an object has at least one ion with an ion-to-surface-distance below this threshold, - the object is considered close to the edge of the dataset. The tool uses a distance-based - approach to solve the in general complicated and involved treatment of computing - volumetric intersections between closed 2-manifolds that are not necessarily convex. - The main practical reason is that such computational geometry analyses face numerical - robustness issues as a consequence of which a mesh can be detected as being completely - inside another mesh although in reality it is only :math:`\epsilon`-close only, i.e. almost - touching only the edge (e.g. from inside). - - Practically, humans would likely still state in such case that the object is close to the - edge of the dataset; however mathematically the object is indeed completely inside. - In short, a distance-based approach is rigorous and flexible. - - - - - Iso-contour values. For each value, the tool computes an iso-surface and performs - subsequent analyses for each iso-surface. The unit depends on the choice for the - normalization of the accumulated ion intensity values per voxel: - - * total, total number of ions, irrespective their iontype - * candidates, total number of ions with type in the isotope_whitelist. - * composition, candidates but normalized by composition, i.e. at.-% - * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 - - - - - Specifies if the tool should report the triangle soup which represents each triangle of the - iso-surface complex. The resulting set of triangles is colloquially referred to as a soup - because different sub-set may not be connected. - - Each triangle is reported with an ID specifying to which triangle cluster (with IDs starting at zero) - the triangle belongs. The clustering of triangles within the soup is performed with a - modified DBScan algorithm. - - - - - Specifies if the tool should analyze for each cluster of triangles how they can be combinatorially - processed to describe a closed polyhedron. Such a closed polyhedron (not-necessarily convex!) - can be used to describe objects with relevance in the microstructure. - - Users should be aware that the resulting mesh does not necessarily represent the original precipitate. - In fact, inaccuracies in the reconstructed positions cause inaccuracies in all downstream processing - operations. Especially the effect on one-dimensional spatial statistics like nearest neighbor correlation - functions were discussed in the literature `B. Gault et al. <https://doi.org/10.1017/S1431927621012952>`_. - - In continuation of these thoughts, this applies also to reconstructed objects. - A well-known example is the discussion of shape deviations of scandium-rich precipitates in aluminium alloys - which in reconstructions may appear as ellipsoids although they should be indeed almost spherical - provided their size is larger than the atomic length scale. - - - - - Specifies if the tool should report a triangulated surface mesh for each identified closed polyhedron. - It is common that a marching cubes algorithm creates iso-surfaces with a fraction of tiny sub-complexes - (e.g. small isolated tetrahedra). - - These can be small tetrahedra/polyhedra about the center of a voxel of the support grid - on which marching cubes operates. Such objects may not contain an ion; especially when considering - that delocalization procedures smoothen the positions of the ions. Although these small objects are - interesting from a numerical point of view, scientists may argue they are not worth to be reported because - a microstructural feature should contain at least a few atoms to become relevant. - Therefore, paraprobe-nanochem by default does not report closed objects which bound a volume - that contains no ion. - - - - - Specifies if the tool should report properties of each closed polyhedron, such - as volume and other details. - - - - - Specifies if the tool should report for each closed polyhedron an approximately optimal bounding box - fitted to all triangles of the surface mesh of the object and ion positions inside or on the surface of the mesh. - This bounding box informs about the closed object's shape (aspect ratios). - - Users should be aware that the choice of the algorithm to compute the bounding box can have an - effect on aspect ratio statistics. It is known that computing the true optimal bounding box of in 3D - is an :math:`\mathcal{O}^3`-time-complex task. The tool uses well-established approximate algorithms - of the Computational Geometry Algorithms Library (CGAL). - - - - - Specifies if the tool should report for each closed polyhedron all evaporation IDs of those ions which - lay inside or on the boundary of the polyhedron. This information is used by the paraprobe-intersector - tool to infer if two objects share common ions, which is then understood as that the two objects intersect. - - Users should be aware that two arbitrarily closed polyhedra in three-dimensional space can intersect - but not share a common ion. In fact, the volume bounded by the polyhedron has sharp edges and flat - face(t)s. When taking two objects, an edge of one object may for instance pierce into the surface of - another object. In this case the objects partially overlap / intersect volumetrically; however this piercing - might be so small or happening in the volume between two reconstructed ion positions. Consequently, - sharing ions is a sufficient but not a necessary condition for interpreting (volumetric) intersections - between objects. - - Paraprobe-intersector implements a rigorous alternative to handle such intersections using a tetrahedralization - of closed objects. However, in many practical cases, we found through examples that there are polyhedra (especially when they are non-convex and have almost point-like) connected channels, where - tetrahedralization libraries have challenges dealing with. In this case, checking intersections - via shared_ions is a more practical alternative. - - - - - Specifies if the tool should report if a (closed) object has contact with the surface aka edge of the dataset. - For this the tool currently inspects if the shortest distance between the set of triangles of the triangulated - surface mesh and the triangles of the edge model is larger than edge_threshold. - If this is the case, the object is assumed to be deeply embedded in the interior of the dataset. - Otherwise, the object is considered to have an edge contact, i.e. it shape is likely affected by the edge. - - - - - Specifies if the tool should analyze a closed polyhedron (aka proxy) for each cluster of triangles whose - combinatorial analysis according to has_object returned that the object is not a closed polyhedron. - Such proxies are closed via iterative hole-filling, mesh refinement, and fairing operations. - - Users should be aware that the resulting mesh does not necessarily represent the original feature. - In most cases objects, precipitates in atom probe end up as open objects because they have been - clipped by the edge of the dataset. Using a proxy is in this case a strategy to still be able to account - for these objects. However, users should make themselves familiar with the consequences and - potential biases which this can introduce into the analysis. - - - - - Like has_object_geometry but for the proxies. - - - - - Like has_object_properties but for the proxies. - - - - - Like has_object_obb but for the proxies. - - - - - Like has_object_ions but for the proxies. - - - - - Like has_object_edge_contact but for the proxies. - - - - - Specifies if the tool should report for each closed object a (cylindrical) region-of-interest (ROI) that gets - placed, centered, and aligned with the local normal for each triangle of the object. - - - - - Specifies if the tool should report for each ROI that was placed at a triangle of each object if this ROI intersects - with the edge the dataset. Currently, the tool supports cylindrical ROIs. A computational geometry test is - performed to check for a possible intersection of each ROI with the triangulated surface mesh that is defined - via surface. Results of this cylinder-set-of-triangles intersection are interpreted as follows: - If the cylinder intersects with at least one triangle of the surface (mesh) the ROI is assumed to make edge contact. - Otherwise, the ROI is assumed to make no edge contact. - - Users should note that this approach does not work if the ROI is laying completely outside the dataset as also - in this case the cylinder intersects with any triangle. However, for atom probe this case is practically irrelevant - provided constructions such as alpha shapes or alpha wrappings (such as paraproeb-surfacer does) about the - ions of the entire reconstructed volume are used. - - - - - - - - Use a principle component analysis (PCA) to mesh a single free-standing interface patch within - the reconstructed volume that is decorated by ions of specific iontypes (e.g. solute atoms). - - Interface_meshing is a typical starting point for the quantification of Gibbsian interfacial excess - in cases when closed objects constructed from patches e.g. iso-surfaces are not available or - when there is no substantial or consistently oriented concentration gradients across an interface - patch. The functionality can also be useful when the amount of latent crystallographic information - within the point cloud is insufficient or when combined with interface_meshing based on ion density - traces in field-desorption maps (see `Y. Wei et al. <https://doi.org/10.1371/journal.pone.0225041>`_ - and `A. Breen et al. <https://github.com/breen-aj/detector>`_ for details). - - Noteworthy to mention is that the method used is conceptually similar to the work of `Z. Peng et al. <https://doi.org/10.1017/S1431927618016112>`_ and related work (DCOM algorithm) by `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_. Compared to these implementations - paraprobe-nanochem uses inspection functionalities which detect potential geometric - inconsistencies or self-interactions of the evolved DCOM mesh. - - - - - - - - - - - - - - - - - - - - - A precomputed triangulated surface mesh representing a model (of the surface) - of the edge of the dataset. This model can be used to detect and control - various sources of bias in the analyses. - - - - - - - - Absolute path in the (HDF5) file that points to the array - of vertex positions for the triangles in that triangle_set. - - - - - Absolute path in the (HDF5) file that points to the array - of vertex indices for the triangles in that triangle_set. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - How is the PCA initialized: - - * default, means based on segregated solutes in the ROI - * control_point_file, means based on reading an external list of - control points, currently coming from the Leoben APT_Analyzer. - - The control_point_file is currently expected with a specific format. - The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. <https://github.com/areichm/APT_analyzer>`_ creates a control_point_file that - can be parsed by paraprobe-parmsetup-nanochem to match the here required - formatting in control_points. - - - - - - - - - Details about the control point file used. - - - - - - - - X, Y, Z position matrix of disjoint control points. - - - - - - Method used for identifying and refining the location of the interface. Currently, - paraprobe-nanochem implements a PCA followed by an iterative loop of isotropic - mesh refinement and DCOM step(s), paired with self-intersection detection. - - - - - - - - Specify those nuclides which the tool should inspect iontypes for if they contain such nuclides. - If this is the case ions of such type are taken with the number of nuclides of this multiplicity found. - The atoms of these ions are assumed to serve as useful markers for locating the interface and - refining the interface mesh. - - - - - - - - - Array of nuclide iontypes to filter. - - - - - - - - - - How many times should the DCOM and mesh refinement be applied? - - - - - Array of decreasing positive not smaller than one nanometer real values - which specify how the initial triangles of the mesh should be iteratively - refined by edge splitting and related mesh refinement operations. - - - - - - - - Array of decreasing positive not smaller than one nanometer real values - which specify the radius of the spherical region of interest within which the - DCOM algorithm decides for each vertex how the vertex might be relocated. - - The larger it is the DCOM radius in relation to the target_edge_length the more - likely it becomes that vertices will be relocated so substantially that triangle - self-intersections may occur. The tool detects these and stops in a controlled - manner so that the user can repeat the analyses with using a different parameterization. - - - - - - - - Array of integers which specify for each DCOM step how many times the mesh - should be iteratively smoothened. Users should be aware that all three arrays - target_edge_length, target_dcom_radius, and target_smoothing_step are interpreted - in the same sequence, i.e. the zeroth entry of each array specifies the respective - parameter values to be used in the first DCOM iteration. The first entry of each array - those for the second DCOM iteration and so on and so forth. - - - - - - - - - Analysis of one-dimensional profiles in ROIs placed in the dataset. - Such analyses are useful for quantifying interfacial excess or for - performing classical composition analyses. - - The tool will test for each ROIs if it is completely embedded in the dataset. - Specifically, each such test evaluates if the ROI cuts at least one triangle - of the triangulated surface mesh that is referred to by surface. - If this is the case the ROI is marked as one close to the surface - and not analyzed further. Otherwise, the ROI is marked as one far - from the surface and processed further. - - For each ROI the tool computes atomically decomposed profiles. - This means, molecular ions are splitted into nuclides as many times as - their respective multiplicity. For each processed ROI the tool stores - a sorted list of signed distance values to enable post-processing with - other software like e.g. reporter to perform classical - Krakauer/Seidman-style interfacial excess analyses. - - Users should be aware that the latter intersection analysis is not - a volumetric intersection analysis. Given that the triangulated mesh - referred to in surface is not required to mesh neither a watertight - nor convex polyhedron a rigorous testing of volumetric intersection - is much more involved. If the mesh is watertight one could use split - the task in first tessellating the mesh into convex polyhedra (e.g. - tetrahedra and apply a volumetric intersection method like the - Gilbert-Johnson-Keerthi algorithm (GJK). In cases when the mesh is not - even watertight distance-based segmentation in combination with again - intersection of triangles and convex polyhedra is a robust but currently - not implemented method to quantify intersections. - - - - - - - - - - - - - - - - - - - - - A precomputed triangulated surface mesh representing a model (of the surface) - of the edge of the dataset. This model can be used to detect and control - various sources of bias in the analyses. - - - - - - - - Absolute path in the (HDF5) file that points to the array - of vertex positions for the triangles in that triangle_set. - - - - - Absolute path in the (HDF5) file that points to the array - of vertex indices for the triangles in that triangle_set. - - - - - - Distance between each ion and triangulated surface mesh. - - - - - - - - Absolute path in the (HDF5) file that points to the distance values. - The tool assumes that the values are stored in the same order as - points (ions). - - - - - - A precomputed triangulated mesh of the feature representing a model of the - interface at which to place ROIs to profile. This can be the mesh of an - interface as returned e.g. by a previous interface_meshing task or the - mesh of an iso-surface from a previous delocalization task. - - - - - - - - Absolute HDF5 path to the dataset that specifies the array of vertex positions. - - - - - Absolute HDF5 path to the dataset that specifies the array of facet indices - which refer to vertices. - - - - - Absolute HDF5 path to the dataset that specifies the array of facet signed unit - normals. - - - - - Absolute HDF5 path to the dataset that specifies the array of vertex signed unit - normals. - - - - - - If interface_model is isosurface this filter can be used to restrict the analysis to specific - patches of an iso-surface. - - - - - - - - To enable an additional filtration of specific parts of the feature - mesh it is recommended to feed precomputed distances of each ion to - the triangles of the feature mesh. - - - - - - - - Absolute path in the (HDF5) file that points to the distance values. - The tool assumes that the values are stored in the same order as - points (ions). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - As an alternative mode the tool can be instructed to place ROIs - at specific locations into the dataset. This is the programmatic - equivalent to the classical approach in atom probe to place ROIs - for composition analyses via positioning and rotating them via - a graphical user interface (such as in IVAS / AP Suite). - - - - - - - - - - - - - - - - - - - - - - - - - - - Which type of distance should be reported for the profile. - - - - - - - - For each ROI, along which direction should the cylindrical ROI - be oriented if ROIs are placed at triangles of the feature mesh. - - - - - - - - For each ROI, how high (projected onto the cylinder axis) should - the cylindrical ROI be if ROIs are placed at triangles - of the feature mesh. - - - - - For each ROI, how wide (in radius) should the cylindrical ROI - be if ROIs are placed at triangles of the feature mesh. - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml deleted file mode 100644 index 4b8e2d3a5..000000000 --- a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml +++ /dev/null @@ -1,1272 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - The total number of atoms in the atomic_decomposition match filter. - - - - - The total number of isotopes in the isotopic_decomposition match filter. - - - - - The dimensionality of the delocalization grid. - - - - - The cardinality/total number of cells/grid points in the delocalization grid. - - - - - - The total number of faces of triangles. - - - - - The total number of XDMF values to represent all faces of triangles via XDMF. - - - - - The total number of entries in a feature dictionary. - - - - - The total number of volumetric features. - - - - - The total number of member distinguished when reporting composition. - - - - - The total number of ROIs placed in an oned_profile task. - - - - - Application definition for results files of the paraprobe-nanochem tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - - - - - - - - - - - - - - - - - - - - - - - - How were results of the kernel-density estimation normalized: - * total, the total number (intensity) of ions or elements. - * candidates, the total number (intensity) of ions matching weighting_model - * composition, the value for candidates divided by the value for total, - * concentration, the value for candidates divided by the volume of the cell. - - - - - - - - - - - The discretized domain/grid on which the delocalization is applied. - - - - - - - - - - - The total number of cells/voxels of the grid. - - - - - - - - - - The symmetry of the lattice defining the shape of the unit cell. - - - - - - - - The unit cell dimensions according to the coordinate system defined under - coordinate_system. - - - - - - - - Number of unit cells along each of the d-dimensional base vectors. - The total number of cells, or grid points has to be the cardinality. - If the grid has an irregular number of grid positions in each direction, - as it could be for instance the case of a grid where all grid points - outside some masking primitive are removed, this extent field should - not be used. Instead use the coordinate field. - - - - - - - - - Integer which specifies the first index to be used for distinguishing identifiers for cells. - Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are - defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. - For explicit indexing the identifier array has to be defined. - - - - - Halfwidth of the kernel about the central voxel. - The shape of the kernel is that of a cuboid - of extent 2*kernel_extent[i] + 1 in each dimension i. - - - - - - - - Functional form of the kernel (Ansatz function). - - - - - - - - Standard deviation :math:`\sigma_i` of the kernel in each dimension - in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - - - - - - - - Expectation value :math:`\mu_i` of the kernel in each dimension - in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - - - - - - - - A tight axis-aligned bounding box about the grid. - - - - For atom probe should be set to true. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - For explicit indexing the identifier array has to be defined. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array - has to be defined. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array - has to be defined. - - - - - Positions of the vertices. - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - - - - - - - - - Six equally formatted sextets chained together. For each sextett the first entry is an - XDMF primitive topology key (here 5 for polygon), the second entry the XDMF - primitive count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - How many distinct boundaries are distinguished? - Most grids discretize a cubic or cuboidal region. In this case - six sides can be distinguished, each making an own boundary. - - - - - Name of the boundaries. E.g. left, right, front, back, bottom, top, - The field must have as many entries as there are number_of_boundaries. - - - - - - - - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet - - - - - - - - - - - The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces - will be computed. In commercial software so far there is no possibility to export this information. - - If the intensity for all matches of the weighting_model are summarized name this NXdata instance - scalar_field_magn_total. - - If the intensity is reported for each iontype one can avoid many subsequent - computations as individual intensities can be reinterpreted using a different weighting_model in - down-stream usage of the here reported values (e.g. with Python scripting). - In this case name the individual NXdata instances scalar_field_magn_ionID using the ID of the ion as - per the configuration of the ranging definitions used. - - - - - - - - - - The actual delocalized intensity values. - - - - - - - - - - Cell center of mass positions along x. - - - - - - - - Cell center of mass positions along y. - - - - - - - - Cell center of mass positions along z. - - - - - - - - Intensity of the field at given point - - - - - - - - Center of mass positions of each voxel for rendering the scalar field - via XDMF in e.g. Paraview. - - - - - - - - - XDMF topology for rendering in combination with xdmf_xyz the scalar field - via XDMF in e.g. Paraview. - - - - - - - - - The three-dimensional gradient :math:`\nabla \Phi`. - Follow the naming convention of scalar_field_magn_SUFFIX to report parallel structures. - - - - - - - - - - The actual point-wise component values. - - - - - - - - - - - Cell center of mass positions along x. - - - - - - - - Cell center of mass positions along y. - - - - - - - - Cell center of mass positions along z. - - - - - - - - The gradient vector formatted for direct visualization via XDMF in e.g. - Paraview. - - - - - - - - - Center of mass positions of each voxel for rendering the scalar field gradient - via XDMF in e.g. Paraview. - - - - - - - - - XDMF topology for rendering in combination with xdmf_xyz the scalar field - via XDFM in e.g. Paraview. - - - - - - - - - - An iso-surface is the boundary between two regions across which the magnitude of a - scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. - - For applications in atom probe microscopy, the location and shape of such a boundary (set) - is typically approximated by discretization - triangulation to be specific. - - This yields a complex of not necessarily connected geometric primitives. - Paraprobe-nanochem approximates this complex with a soup of triangles. - - - - - The threshold or iso-contour value :math:`\varphi`. - - - - - Details about the specific marching cubes algorithm that was used for computing - the iso-surface. - - - - Reference to the specific implementation of marching cubes used. - The value placed here should be a DOI. If there are no specific - DOI or details write not_further_specified, or give at least a - free-text description. The program and version used is the - specific paraprobe-nanochem. - - - - - - The resulting triangle soup computed via marching cubes. - - - - - - Integer which specifies the first index to be used for distinguishing triangles. - Identifiers are defined either implicitly or explicitly. For implicit indexing the - identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to a unique set as this may - result in a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. Naively here means that each - vertex is stored even though many share the same positions. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - - - - - - - - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tri * (1+1+3). - - - - - - - - - Direction of each normal. - - - - - - - - - Qualifier how which specifically oriented normal to its - primitive each normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - - - - - - - - - - - Direction of each normal. - - - - - - - - - Qualifier how which specifically oriented normal to its - primitive each normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - - - - - - - - Triangle normals are oriented in the direction of the - gradient vector of the local delocalized scalar field. - :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. - - - - - - - - - Triangle normals are oriented in the direction of the - gradient vector of the local delocalized scalar field. - The projection variable here describes the cosine of the - angle between the gradient direction and the normal - direction vector. - This is a descriptor of how parallel the projection is - that is especially useful to document those triangles - for whose the projection is almost perpendicular. - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length - is reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle - is reported for the angle opposite to the edges which are - traversed according to the sequence in which vertices - are indexed in triangles. - - - - - - - - - The center of mass of each triangle. - - - - - - - - - Iso-surfaces of arbitrary scalar three-dimensional fields can show a complicated topology. - Paraprobe-nanochem can run a DBScan-like clustering algorithm which performs a - connectivity analysis on the triangle soup representation of such iso-surface. - This may yield a set of connected features whose individual surfaces are discretized - by a triangulated mesh each. Such volumetric features can be processed further using - paraprobe-nanochem using a workflow with at most two steps. - - In the first step, the tool distinguishes three types of (v) i.e. volumetric features: - - 1. So-called objects, i.e. necessarily watertight features represented by polyhedra. - These objects were already watertight within the triangulated iso-surface. - 2. So-called proxies, i.e. features that were not necessarily watertight within the triangulated - iso-surface but were subsequently replaced by a watertight mesh using polyhedral mesh - processing operations (hole filling, refinement, fairing operations). - 3. Remaining triangle surface meshes or parts of these of arbitrary shape and cardinality - that are not transformable into proxies or for which no transformation into proxies was - instructed. - - These features can be interpreted as microstructural features. Some of them may be precipitates, - some of them may be poles, some of them may be segments of dislocation lines or other - crystal defects which are decorated (or not) with solutes. - - In the second step, the tool can be used to analyze the proximity of these objects to a - model of the surface (edge) of the dataset. - - - - The identifier which the triangle_soup connectivity analysis - returned, which constitutes the first step of the - volumetric_feature identification process. - - - - - - - - The array of keywords of feature_type dictionary. - - - - - - - - The array of values for each keyword of the - feature_type dictionary. - - - - - - - - The array of controlled keywords, need to be from - feature_type_dict_keyword, which specify which type - each feature triangle cluster belongs to. - Keep in mind that not each feature is an object or proxy. - - - - - - - - The explicit identifier of features. - - - - - - - - In all situations instances of the parent NXprocess group are returned with a very similar - information structuring and thus we here replace the template name FEATURE - with one of the following types feature-specific group names: - - * objects, objects, irrespective their distance to the surface - * objects_close_to_edge, sub-set of v_feature_object close surface - * objects_far_from_edge, sub-set of v_feature_object not close to the surface - * proxies, proxies, irrespective their distance to the surface - * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface - * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface - - - - Explicit identifier of the feature a sub-set of the feature_identifier in the - parent group. - - - - - - - - Volume of the feature. NaN for non-watertight objects. - - - - - - - - An oriented bounding box (OBB) to each object. - - - - Edge length of the oriented bounding box from largest to smallest value. - - - - - - - - - Oriented bounding box aspect ratio. - YX versus ZY or second-largest over largest and smallest over second largest. - - - - - - - - - Position of the geometric center, which often is but - not necessarily has to be the center_of_mass of the - hexahedrally-shaped sample/sample part. - - - - - - - - - A simple approach to describe the entire set of hexahedra when the main intention - is to store the shape of the hexahedra for visualization. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Array of evaporation_identifier / ion_identifier which details which ions - lie inside or on the surface of the feature. - - - - - - - - - - - Total (count) of ions inside or on the surface of the feature relevant for normalization. - NaN for non watertight objects. - - - - - - - - - - - - - Count or weight which, when divided by total, yields the composition of this element, - nuclide, or (molecular) ion within the volume of the feature/object. - - - - - - - - - - - - - - - - - - - - - - - - The multiplicity whereby the ion position is accounted for - irrespective whether the ion is considered as a decorator - of the interface or not. - As an example, with atom probe it is typically not possible - to resolve the positions of the atoms which arrive at the detector - as molecular ions. Therefore, an exemplar molecular ion of two carbon - atoms can be considered to have a multiplicity of two to account that - this molecular ion contributes two carbon atoms at the reconstructed - location considering that the spatial resolution of atom probe - experiments is limited. - - - - - - - - The multiplicity whereby the ion position is accounted for when - the ion is considered one which is a decorator of the interface. - - - - - - - - The equation of the plane that is fitted initially. - - - - The four parameter :math:`ax + by + cz + d = 0` which define the plane. - - - - - - - - - The triangle surface mesh representing the interface model. - Exported at state before or after the next DCOM step. - - - - Was this state exported before or after the next DCOM step. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Direction of each vertex normal. - - - - - - - - - Qualifier which details how specifically oriented the - face normal is with respect to its primitive (triangle): - - * 0 - undefined - * 1 - outer - * 2 - inner - - - - - - - - - - - - - - Direction of each face normal. - - - - - - - - - Qualifier which details how specifically oriented the - face normal is with respect to its primitive (triangle): - - * 0 - undefined - * 1 - outer - * 2 - inner - - - - - - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - - - - - - - - - - The ROIs are defined as cylinders for the computations. To visualize these we discretize - them into regular n-gons. Using for instance 360-gons, i.e. a regular n-gon with 360 edges, - resolves the lateral surface of each cylinder such that their renditions are smooth in - visualization software like Paraview. - - - - - - Position of the geometric center, which often is but not - necessarily has to be the center_of_mass of the polyhedra. - - - - - - - - - The orientation of the ROI defined via a vector which points along - the cylinder axis and whose length is the height of the cylinder. - - - - - - - - - - XDMF support to enable colouring each ROI by its identifier. - - - - - - - - XDMF support to enable colouring each ROI whether it has edge contact or not. - - - - - - - - XDMF support to enable colouring each ROI by its number of atoms. - - - - - - - - XDMF support to enable colouring each ROI by its number of ions. - - - - - - - - Distance and iontype-specific processed data for each ROI. - Arrays signed_distance and nuclide_hash are sorted by increasing - distance. - Array nuclide_hash reports one hash for each atom of each isotope. - Effectively, this can yield to groups of values on signed_distance - with the same distance value as molecular ions are reported decomposed - into their atoms. - Therefore, the XDMF support fields number_of_atoms and number_of_ions - are only expected to display pairwise the same values respectively, - if all ions are built from a single atom only. - - - - - Sorted in increasing order projected along the positive direction - of the ROI as defined by orientation in the parent group. - - - - - - - - Hashvalue as defined in :ref:`NXion`. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml deleted file mode 100644 index 3282c203d..000000000 --- a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The number of isotopes to consider as building blocks for searching molecular - ions. - - - - - The number of compositions to consider for molecular ion search tasks. - - - - - Application definition for a configuration file of the paraprobe-ranger tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml deleted file mode 100644 index de5680a96..000000000 --- a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml +++ /dev/null @@ -1,139 +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-ranger tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The purpose and need of the paraprobe-ranger tool is to apply a given set of ranging definitions within - a certain (possibly complicated) selection of ions (based on their properties or location in the - reconstructed volume. - - - - - - - - - - - - Paraprobe-ranger loads the iontypes and evaluates for each - ion on which iontype it matches. If it matches on None, the - ion is considered of the default *unknown_type*. This iontype - is marked with a 0 in the iontypes array. - - - - - - - - - - - - - - - - - - The iontype (identifier) for each ion that was best matching, stored - in the order of the evaporation sequence ID. The here computed iontypes - do not take into account the charge state of the ion which is - equivalent to interpreting a RNG and RRNG range files for each - ion in such a way that only the those elements are considered of which - a (molecular) ion is assumed composed according to the NXion instances. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml new file mode 100644 index 000000000..eb8979497 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml @@ -0,0 +1,503 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The total number of entries in the restricted_identifier dictionary. + + + + + Results of a paraprobe-clusterer tool run. + + + + + + Version specifier of this application definition. + + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must no longer compute analyses. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases, it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + If nothing else is specified we assume that there + has to be at least one set of NXtransformations named + paraprobe defined, which specifies the coordinate system. + In which all positions are defined. + + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + A bitmask which identifies which of the ions in the dataset were + analyzed during this process. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used, padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe-toolbox executable. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth (padding). + + + + + + + + + The result of a cluster analyses. These include typically the label for + each ion/point documenting to which feature (if any) an ion is assigned. + Typically, each analysis/run yields only a single cluster. + In cases of fuzzy clustering it can be possible that an ion is assigned + to multiple cluster (eventually with different) weight/probability. + + + + Results of a DBScan clustering analysis. + + + + The epsilon (eps) parameter. + + + + + The minimum points (min_pts) parameter. + + + + + Number of members in the set which is partitioned into features. + Specifically, this is the total number of targets filtered from the + dataset. Cardinality here is not the total number of ions in the + dataset. + + + + + + Which identifier is the first to be used to label a cluster. + + The value should be chosen in such a way that special values can be resolved: + * identifier_offset-1 indicates an object belongs to no cluster. + * identifier_offset-2 indicates an object belongs to the noise category. + Setting for instance identifier_offset to 1 recovers the commonly used + case that objects of the noise category get values to -1 and unassigned points to 0. + Numerical identifier have to be strictly increasing. + + + + + + The evaporation sequence identifier to figure out which ions + from the reconstruction were considered targets. + + + + + + + + + The raw labels from the DBScan clustering backend process. + + + + + + + + The raw array of core sample indices which specify which of the + targets are core points. + + + + + + + + + Matrix of numerical label for each member in the set. + For classical clustering algorithms this can for instance + encode the cluster_identifier. + + + + + + + + + The array of weight which specifies how surely/likely the + cluster is associated/assigned to a specific identifier as + is specified in the cluster_identifier array. + For the DBScan and atom probe tomography the multiplicity + of each ion with respect to the cluster. That is how many times + should the position of the ion be accounted for because the ion + is e.g. a molecular ion with several elements or isotope of + requested type. + + + + + + + + Optional bitmask encoding if members of the set are assigned to as noise or not. + + + + + + + + Optional bitmask encoding if member of the set are a core point. + For details to which feature/cluster an ion/point is a core point + consider numerical_label. + + + + + + + + In addition to the detailed storage which members was grouped to + which feature/group summary statistics are stored under this group. + + + + + Total number of members in the set which are categorized as noise. + + + + + + Total number of members in the set which are categorized as a core point. + + + + + + Total number of clusters (excluding noise and unassigned). + + + + + Array of numerical identifier of each feature (cluster). + + + + + + + + Array of number of members for each feature. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml new file mode 100644 index 000000000..54ad4dcca --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml @@ -0,0 +1,388 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The total number of triangles in the set. + + + + + Results of a paraprobe-distancer tool run. + + + + + + Version specifier of this application definition. + + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + The tool can be used to compute the analytical distance of each ion + to a set of triangles. + + + + A bitmask which identifies which of the ions in the dataset were + analyzed. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of the triangles in the set + were considered. Usually these are all but sometimes users may + wish to filter certain portions of the triangles out. + If window_triangles is not provided it means that + all triangles were taken. + + + + Number of triangles covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + The closest analytical distance of the ions to their respectively + closest triangle from the triangle set. + + + + + + + + A bitmask which identifies which of the distance values + can be assumed to have a consistent sign because the closest + triangle had a consistent outer unit normal defined. + For points whose bit is set 0 the distance is correct but the + sign is not reliable. + + + + Number of triangles covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. + + + + + + + + + The identifier of the triangle that is closest for each ion. + + + + + + + + A support field to visualize each ion and with this the distance + informations using XDMF and e.g. Paraview. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml new file mode 100644 index 000000000..1c60505c7 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml @@ -0,0 +1,395 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of links pointing from current to next. + + + + + The total number of links pointing from next to current. + + + + + The total number of members in the current_set. + + + + + The total number of members in the next_set. + + + + + The total number of cluster found for coprecipitation analysis. + + + + + The number of rows in the table/matrix for coprecipitation stats. + + + + + Results of a paraprobe-intersector tool run. + + + + + + Version specifier of this application definition. + + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + The results of an overlap/intersection analysis. + + + + A matrix of feature_identifier which specifies which named features + from the current set have directed link(s) pointing to which named + feature(s) from the next set. + + + + + + + + + For each link/pair in current_to_next a characterization + whether the link is due to a volumetric overlap (0x00 == 0), + proximity (0x01 == 1), or something else unknown (0xFF == 255). + + + + + + + + A matrix of feature_identifier which specifies which named feature(s) + from the next set have directed link(s) pointing to which named + feature(s) from the current set. Only if the mapping whereby the + links is symmetric next_to_current maps the links in current_to_next + in the opposite direction. + + + + + + + + + For each link/pair in next_to_current a characterization + whether the link is due to a volumetric overlap (0x00 == 0), + proximity (0x01 == 1), or something else unknown (0xFF == 255). + + + + + + + + For each pair of links in current_to_next the volume of the + intersection, i.e. how much volume do the two features share. + If features do not intersect the volume is zero. + + + + + + + + During coprecipitation analysis the current and next set are analyzed + for links in a special way. Three set comparisons are made. Members + of the set in each comparison are analyzed for overlap and proximity: + + The first comparison is the current_set against the current_set. + The second comparison is the next_set against the next_set. + The third comparison is the current_set against the next_set. + + Once the (forward) links for these comparisons are ready the + pair relations are analyzed with respect to which feature identifier + cluster in identifier space. Thereby a logical connection (link) is + established between the features in the current_set and next_set. + Recall that these two set typically represent different features + within an observed system for otherwise the same parameterization. + Examples include two sets of e.g. precipitates with differing + chemical composition that were characterized in the same material + volume representing a snapshot of an e.g. microstructure at the same + point in time. Researchers may have performed two analyses, one to + characterize precipitates A and another one to characterize percipitates + B. Coprecipitation analysis now logically connects these independent + characterization results to establish spatial correlations of e.g. + precipitates spatial arrangement. + + + + Matrix of feature_identifier and cluster_identifier pairs which + encodes the cluster to which each feature_identifier was assigned. + Here for features of the current_set. + + + + + + + + + Matrix of feature_identifier and cluster_identifier pairs which + encodes the cluster to which each feature_identifier was assigned. + Here for features of the next_set. + + + + + + + + + The identifier (names) of the cluster. + + + + + + + + Pivot table as a matrix. The first column encodes how many + members from the current_set are in each cluster, one row per cluster. + The second column encodes how many members from the next_set are + in each cluster, in the same row per cluster respectively. + The last column encodes the total number of members in the cluster. + + + + + + + + + Pivot table as a matrix. The first column encodes the different + types of clusters based on their number of members in the sub-graph. + The second column encodes how many clusters with as many members + exist. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml new file mode 100644 index 000000000..aae16541e --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml @@ -0,0 +1,1965 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The total number of atoms in the atomic_decomposition match filter. + + + + + The total number of isotopes in the isotopic_decomposition match filter. + + + + + The dimensionality of the delocalization grid. + + + + + The cardinality/total number of cells/grid points in the delocalization grid. + + + + + + The total number of XDMF values to represent all faces of triangles via XDMF. + + + + + The total number of entries in a feature dictionary. + + + + + The total number of member distinguished when reporting composition. + + + + + Results of a paraprobe-nanochem tool run. + + + + + + Version specifier of this application definition. + + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must no longer compute analyses. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases, it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + If nothing else is specified we assume that there + has to be at least one set of NXtransformations named + paraprobe defined, which specifies the coordinate system. + In which all positions are defined. + + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + A bitmask which identifies which of the ions in the dataset were + analyzed during this process. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used, padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe-toolbox executable. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth (padding). + + + + + + + + + + + The weighting model specifies how mark data are mapped to a weight + per point/ion. For atom probe microscopy (APM) mark data are e.g. + which iontype an ion has. As an example, different models are used + which account differently for the multiplicity of a point/ion + during delocalization: + + * unity, all points/ions get the same weight 1. + * atomic_decomposition, points get as much weight as they + have atoms of a type in atomic_decomposition_rule, + * isotope_decomposition, points get as much weight as they have + isotopes of a type in isotopic_decomposition_rule. + + + + + + + + + + + A list of elements (via proton number) to consider for the + atomic_decomposition weighting model. + Elements must exist in the periodic table of elements and be + specified by their number of protons. + Values in match are isotope hash values using the following + hashing rule $H = Z + 256*N$ with $Z$ the number of protons + and $N$ the number of neutrons of the isotope. + In the case of elements this hashing rule has the advantage + that for elements the proton number is their hash value because + N is zero. + + + + Meaning of the filter: + Whitelist specifies which entries with said value to include. + Entries with all other values will be filtered out. + + Blacklist specifies which entries with said value to exclude. + Entries with all other values will be included. + + + + + + + + + Array of values to filter according to method. For example, + if the filter specifies [1, 5, 6] and method is whitelist, + only entries with values matching 1, 5 or 6 will be processed. + All other entries will be filtered out/not considered. + + + + + + + + + A list of isotopes (via proton and neutron number) to consider + for the isotopic_decomposition weighting model. + Isotopes must exist in the nuclid table. + Values in match are isotope hash values using the following + hashing rule $H = Z + 256*N$ with $Z$ the number of protons + and $N$ the number of neutrons of the isotope. + + + + Meaning of the filter: + Whitelist specifies which entries with said value to include. + Entries with all other values will be filtered out. + + Blacklist specifies which entries with said value to exclude. + Entries with all other values will be included. + + + + + + + + + Array of values to filter according to method. For example, + if the filter specifies [1, 5, 6] and method is whitelist, + only entries with values matching 1, 5 or 6 will be processed. + All other entries will be filtered out/not considered. + + + + + + + + + How results of the kernel-density estimation were computed + into quantities. By default the tool computes the total number + (intensity) of ions or elements. Alternatively the tool can compute + the total intensity, the composition, or the concentration of the + ions/elements specified by the white list of elements in each voxel. + + + + + + + + + + + Weighting factor, in atom probe, often termed multiplicity. + The weighting factor is the multiplier with which the integrated + intensity contribution from the point/ion gets multiplied. + The delocalization computes the integrated intensity for each + grid cell. Effectively, this is an explicitly evaluated kernel + method where each specific position of an ion is replaced by a + smoothing kernel. For atom probe weights are positive and integer + specifically the multiplicity of the ion, in accordance with the + respective rulesets as defined by weighting_model. + + + + + + + + The discretized domain/grid on which the delocalization is applied. + + + + + + + + + + + The total number of cells/voxels of the grid. + + + + + + + + + + The symmetry of the lattice defining the shape of the unit cell. + + + + + + + + The unit cell dimensions according to the coordinate system + defined under coordinate_system. + + + + + + + + Number of unit cells along each of the d unit vectors. + The total number of cells, or grid points has to be the cardinality. + If the grid has an irregular number of grid positions in each direction, + as it could be for instance the case of a grid where all grid points + outside some masking primitive are removed, this extent field should + not be used. Instead use the coordinate field. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + If the coordinate system is not specified the paraprobe + coordinate system is used. + + + + + + Integer which specifies the first index to be used for + distinguishing identifiers for cells. Identifiers are defined + either implicitly or explicitly. For implicit indexing the + identifiers are defined on the interval + [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + + + + A tight axis-aligned bounding box about the grid. + + + + For atom probe should be set to true. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. + + + + + + Name of the boundaries. E.g. left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. + + + + + + + + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + + + + + + + + + + The result of the delocalization based on which subsequent + iso-surfaces will be computed. In commercial software so far + there is not a possibility to export such grid. + + + + + + + + + + + + + + + + + + Cell center of mass positions along x. + + + + + + + + + Cell center of mass positions along y. + + + + + + + + Cell center of mass positions along z. + + + + + + + + Intensity of the field at given point + + + + + + + + Center of mass positions of each voxel for + rendering the scalar field via XDMF in e.g. + Paraview. + + + + + + + + + XDMF topology for rendering in combination with + xdmf_xyz the scalar field via XDFM in e.g. Paraview. + + + + + + + + + The three-dimensional gradient nabla operator applied to + scalar_field_magnitude. + + + + + + + + + + + + + + + + + + + + Cell center of mass positions along x. + + + + + + + + + Cell center of mass positions along y. + + + + + + + + Cell center of mass positions along z. + + + + + + + + The gradient vector. + + + + + + + + + Center of mass positions of each voxel for + rendering the scalar field via XDMF in e.g. + Paraview. + + + + + + + + + XDMF topology for rendering in combination with + xdmf_xyz the scalar field via XDFM in e.g. Paraview. + + + + + + + + + Halfwidth of the kernel about the central voxel. + The shape of the kernel is that of a cuboid + of extent 2*kernel_extent[i] + 1 in each dimension i. + + + + + + + + + + Sigma of the kernel in each dimension in the paraprobe + coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + + + + + + + + Expectation value of the kernel in each dimension in the paraprobe + coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + + + + + + + + + + An iso-surface is the boundary between two regions across which + the magnitude of a scalar field falls below/exceeds a threshold + magnitude phi. + For applications in atom probe microscopy the location and shape + of such a boundary (set) is typically approximated by + discretization. + This yields a complex of not necessarily connected geometric + primitives. Paraprobe-nanochem approximates this complex with + a soup of triangles. + + + + + The threshold or iso-contour value. + + + + + Details about the specific marching cubes algorithm + which was taken to compute the iso-surface. + The grid is the delocalization grid. + + + + Reference to the specific implementation of marching cubes used. + The value placed here should be a DOI. If there are no specific + DOI or details write not_further_specified, or give at least a + free-text description. The program and version used is the + specific paraprobe-nanochem. + + + + + + The resulting triangle soup computed via marching cubes. + + + + + + Integer which specifies the first index to be used for + distinguishing triangles. Identifiers are defined either + implicitly or explicitly. For implicit indexing the + identifiers are defined on the interval + [identifier_offset, identifier_offset+c-1]. + + + + + + Number of vertices. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tri * (1+1+3). + + + + + + + + + Direction of each normal. + + + + + + + + + Qualifier how which specifically oriented normal to its + primitive each normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + + + + Direction of each normal. + + + + + + + + + Qualifier how which specifically oriented normal to its + primitive each normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + Triangle normals are oriented in the direction of the + gradient vector of the local delocalized scalar field. + :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. + + + + + + + + + Triangle normals are oriented in the direction of the + gradient vector of the local delocalized scalar field. + The projection variable here describes the cosine of the + angle between the gradient direction and the normal + direction vector. + This is a descriptor of how parallel the projection is + that is especially useful to document those triangles + for whose projection is almost perpendicular. + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length + is reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle + is reported for the angle opposite to the edges which are + traversed according to the sequence in which vertices + are indexed in triangles. + + + + + + + + + The center of mass of each triangle. + + + + + + + + + + Iso-surfaces of arbitrary scalar three-dimensional fields + can show a complicated topology. Paraprobe-nanochem can run + a DBScan-like clustering algorithm which performs a + connectivity analysis on the triangle soup. This yields a + set of connected features with their surfaces discretized + by triangles. Currently, the tool distinguishes at most + three types of features: + + 1. So-called objects, i.e. necessarily watertight features + represented polyhedra. + 2. So-called proxies, i.e. features that were replaced by a + proxy mesh and made watertight. + 3. Remaining triangle surface meshes of arbitrary shape and + cardinality. + + These features can be interpreted as microstructural features. + Some of them may be precipitates, some of them may be poles, + some of them may be segments of dislocation lines or other + crystal defects which are decorated (or not) with solutes. + + + + + The identifier which the triangle_soup connectivity analysis + returned, which constitutes the first step of the + volumetric_feature identification process. + + + + + + + + The array of keywords of feature_type dictionary. + + + + + + + + The array of values for each keyword of the + feature_type dictionary. + + + + + + + + The array of controlled keywords, need to be from + feature_type_dict_keyword, which specify which type + each feature triangle cluster belongs to. + Keep in mind that not each feature is an object or proxy. + + + + + + + + The explicit identifier of features. + + + + + + + + + Details for features which are (closed) objects. + Identifier have to exist in feature_identifier. + + + + + + + + + + + + + + + An oriented bounding box (OBB) to each object. + + + + Edge length of the oriented bounding box from largest + to smallest value. + + + + + + + + + + Oriented bounding box aspect ratio. YX versus ZY. + + + + + + + + + Position of the geometric center, which often is but + not necessarily has to be the center_of_mass of the + hexahedrally-shaped sample/sample part. + + + + + + + + + + A simple approach to describe the entire set of hexahedra + when the main intention is to store the shape of the + hexahedra for visualization. + + + + + + + + + + + + + + + + + + + + + + + + Details for all those objects close to edge, i.e. those which + have at least one ion which lays closer to a modelled edge + of the dataset than threshold. + + + + + + + + + + + + + + + Total (count) relevant for normalization. + + + + + + + + + + + + Count or weight which, when divided by total, + yields the composition of this element, isotope, + molecule or ion. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Array of evaporation_identifier / ion_identifier which + specify ions laying inside or on the surface of the feature. + + + + + + + + + + + Details for all those objects far from edge, i.e. those + whose ions lay all at least threshold distant from a + modelled edge of the dataset. + + + + + + + + + + + + + + + Total (count) relevant for normalization. + + + + + + + + + + + + Count or weight which, when divided by total + yields the composition of this element, isotope, + molecule or ion. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Array of evaporation_identifier / ion_identifier which + specify ions laying inside or on the surface of the feature. + + + + + + + + + + + + + Details for features which are so-called proxies, i.e. objects + which have been reconstructed and combinatorially closed with + processing their partial triangulated_surface_mesh + (hole filling, refinement). + Identifier have to exist in feature_identifier. + + + + + + + + + + + + + + + + Details for those proxies close to edge, i.e. those which + have at least one ion which lays closer to a modelled edge + of the dataset than threshold. + Identifier have to exist in feature_identifier. + + + + + + + + + + + + + + + + Total (count) relevant for normalization. + + + + + + + + + + Count or weight which, when divided by total + yields the composition of this element, isotope, + molecule or ion. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Array of evaporation_identifier / ion_identifier which + specify ions laying inside or on the surface of the feature. + + + + + + + + + + + Details for those proxies far from edge, i.e. those whose + ions lay all at least threshold distant from a + modelled edge of the dataset. + + + + + + + + + + + + + + + Total (count) relevant for normalization. + + + + + + + + + + Count or weight which, when divided by total + yields the composition of this element, isotope, + molecule or ion. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Array of evaporation_identifier / ion_identifier which + specify ions laying inside or on the surface of the feature. + + + + + + + + + + + + + + + + + + The multiplicity whereby the ion position is accounted for + irrespective whether the ion is considered as a decorator + of the interface or not. + As an example, with atom probe it is typically not possible + to resolve the positions of the atoms which arrive at the detector + as molecular ions. Therefore, an exemplar molecular ion of two carbon + atoms can be considered to have a multiplicity of two to account that + this molecular ion contributes two carbon atoms at the reconstructed + location considering that the spatial resolution of atom probe + experiments is limited. + + + + + + + + The multiplicity whereby the ion position is accounted for when + the ion is considered one which is a decorator of the interface. + + + + + + + + The equation of the plane that is fitted initially. + + + + The four parameter :math:`ax + by + cz + d = 0` which define the plane. + + + + + + + + + The triangle surface mesh representing the interface model. + Exported at some iteration before the next DCOM step. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Direction of each normal + + + + + + + + + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + + + + + Direction of each normal + + + + + + + + + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + + The triangle surface mesh representing the interface model. + Exported at some iteration after the next DCOM step. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Direction of each normal + + + + + + + + + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + + + + + Direction of each normal + + + + + + + + + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + + + + The ROIs are defined as cylinders for the computations. + To visualize these though we discretize them into regular n-gons. + Using for instance a 360-gon, i.e. a regular n-gon with 360 + edges resolves the lateral surface of each cylinder very finely + so that they are rendered smoothly in visualization software. + + + + + + Position of the geometric center, which often is but not + necessarily has to be the center_of_mass of the polyhedra. + + + + + + + + + Integer which specifies the first index to be used for distinguishing + ROI cylinder. Identifiers are defined explicitly. + + + + + + + + + + + + + + + The number of atoms in each ROI. + + + + + + + + The number of ions in each ROI. + + + + + + + + The orientation of the ROI defined via a vector which points along + the cylinder axis and whose length is the height of the cylinder. + + + + + + + + + + In the direction of the ROI. + + + + + Hashvalue + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml new file mode 100644 index 000000000..52e41fca5 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml @@ -0,0 +1,425 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Results of a paraprobe-ranger tool run. + + + + + + Version specifier of this application definition. + + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + Paraprobe-ranger loads the iontypes and evaluates for each + ion on which iontype it matches. If it matches on none, the + ion is considered of the default unknown type with a 0 as its + respective value in the iontypes array. + + + + + The length of the isotope_vector used to describe molecular ions. + + + + + + + + + + + The iontype ID for each ion that was best matching, stored in the + order of the evaporation sequence ID. The here computed iontypes + do not take into account the charge state of the ion which is + equivalent to interpreting a RNG and RRNG range files for each + ion in such a way that only the elements of which a (molecular) ion + is build are considered. By contrast, charged_iontypes takes + into account also the charge state. + + + + + + + + A bitmask which identifies exactly all those ions ranged irrespective + the type they ended up with. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + + Paraprobe-ranger performs a combinatorial search over + all possible or a reduced set of nuclids to identify + into which ions these can be composed. + + + + The main result is the list of molecular ions, here formatted + according to the definitions of a set of isotope_vectors + as detailed in :ref:`NXion`. + + + + + + + + + The mass-to-charge-state ratio of each molecular ion + without considering relativistic or quantum effects. + + + + + + + + The mass of each molecular ion without + considering relativistic or quantum effects. + + + + + + + + + The charge_state of each molecular ion. + + + + + + + + The product of the natural abundance of the isotopes building + each molecular ion. Further details are available in + :ref:`NXapm_paraprobe_config_ranger`. + + + + + + + + The product of the natural abundance of the isotopes building + each molecular ion. Further details are available in + :ref:`NXapm_paraprobe_config_ranger`. + + + + + + + + The number of disjoint nuclids for each molecular ion. + + + + + + + + The number of nuclids for each molecular ion. + + + + + + + + + Paraprobe-ranger loads iontypes and evaluates for each ion on which + iontype it matches. If it matches on none, the ion is considered of + the default unknown type with a 0 as its respective value in the + iontypes array. In contrast to use_existent_ranging this process + does neither needs measured ion position nor mass-to-charge-state + ratio values. + + + + + The length of the isotope_vector used to describe molecular ions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml new file mode 100644 index 000000000..38fac7096 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml @@ -0,0 +1,274 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + Results of a paraprobe-selector tool run. + + + + + + Version specifier of this application definition. + + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + A bitmask which identifies which of the ions in the dataset + were selected to become included in the region-of-interest (ROI). + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml new file mode 100644 index 000000000..d87d2f50f --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml @@ -0,0 +1,364 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + Results of a paraprobe-spatstat tool run. + + + + + + Version specifier of this application definition. + + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + A bitmask which identifies which of the ions in the dataset were + analyzed. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + The iontype ID for each ion that was assigned to each ion during + the randomization of the ionlabels. Iontype labels are just permuted + but the total number of values for each iontype stay the same. + + The order matches the iontypes array from a given ranging results + as is specified in the configuration settings inside the specific + config_filename that was used for this spatstat analysis. + + + + + + + + K-nearest neighbor statistics. + + + + Right boundary of the binning. + + + + + + + + + + + + + Cumulated + + + + + + + + Cumulated and normalized by total counts + + + + + + + + + Radial distribution statistics. + + + + Right boundary of the binning. + + + + + + + + + + + + + Cumulated + + + + + + + + Cumulated and normalized by total counts + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml new file mode 100644 index 000000000..dbb0bb4e4 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml @@ -0,0 +1,503 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The number of vertices of the alpha complex. + + + + + The number of faces of the alpha complex. + + + + + The total number of XDMF values to represent all faces of triangles via XDMF. + + + + + The total number of XDMF values to represent all faces of tetrahedra via XDMF. + + + + + Results of a paraprobe-surfacer tool run. + + + + + + Version specifier of this application definition. + + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + A bitmask which identifies which of the ions in the dataset were + analyzed. Computations of alpha complexes may have filtered this + ion set further but this process is deterministic. + + + + Number of ions covered by the mask. The mask may be 0 for most. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + Paraprobe-surfacer can be used to load a ROI that is the entire or a + sub-set of the ion point cloud. In the point_cloud_wrapping process + the tool computes a triangulated surface mesh which encloses the + ROI/point cloud. This mesh can be seen as a model for the edge of + the dataset. + Different algorithms can be used with paraprobe-surfacer to create + this mesh such as convex hulls, alpha-shapes as their generalization, + or alpha wrappings. + Ideally, the resulting mesh should be a watertight polyhedron. + This polyhedron is not necessarily convex. For some algorithms there + is no guarantee that the resulting mesh yields a watertight mesh. + + + + + + A bitmask which identifies exactly all those ions whose positions + were considered when defining the filtered point set from which + the alpha complex was then in fact computed. This window + can be different to the entire window as irrelevant ions might + have been filtered out to reduce the computational costs of the + alpha complex analysis. + + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The set of triangles in the coordinate system paraprobe + which discretizes the exterior surface of the alpha complex. + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + + + + + + + Number of vertices. + + + + + Number of faces. + + + + + + + + + + + + + + + + + + + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tri * (1+1+3). + + + + + + + + + Do the triangles define a triangulated surface mesh which + is watertight? + + + + + The volume which the triangulated surface mesh encloses + provided that the mesh is watertight. + + + + + + The set of tetrahedra which represent the interior volume of the + complex if that is a closed 2-manifold. + + + + Integer which specifies the first index to be used for distin- + guishing tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined + on the interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + + + + The accumulated volume of all interior tetrahedra. + + + + + + Number of vertices. + + + + + Number of faces. + + + + + + + + + + + + + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tet * (1+1+4). + + + + + + + + + + + + In the future we may want to wrap other primitives + like triangles or polylines. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml new file mode 100644 index 000000000..4d8eb2476 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml @@ -0,0 +1,677 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The total number of facets/polygons defining the tessellation. + + + + + Results of a paraprobe-tessellator tool run. + + + + + + Version specifier of this application definition. + + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + The tool can be used to compute a Voronoi tessellation the entire + or a sub-set of the reconstruction. The point cloud in the ROI is + wrapped into a tight axis-aligned bounding box. The tool detects if + Voronoi cells make contact with the walls of this bounding box. + The tessellation is computed without periodic boundary conditions. + + + + A bitmask which identifies which of the ions in the dataset were + analyzed. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by the global axis-aligned bounding box, i.e. boundaries + of the threads are ignored. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The left wall has the negative x axis of the paraprobe coordinate + system as the outer unit normal. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The right wall has the positive x axis of the paraprobe coordinate + system as the outer unit normal. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The front wall has the negative y axis of the paraprobe coordinate + system as the outer unit normal. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The rear wall has the positive y axis of the paraprobe coordinate + system as the outer unit normal. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The left wall has the negative z axis of the paraprobe coordinate + system as the outer unit normal. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The left wall has the positive z axis of the paraprobe coordinate + system as the outer unit normal. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + + + + + + + + Interior volume + + + + + + + + By which MPI process was the Voronoi cell computed. + + + + + + + + By which OpenMP thread was the Voronoi cell computed. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + A simple approach to describe the entire set of polyhedra when + the main intention is to store the shape of the polyhedra for + visualization. + + + + + Number of vertices. + + + + + Number of faces. + + + + + + + + + + + + + A sequence of always first an XDMF topology type key, followed + by the XDMF number of vertices of the polygon, followed by + the vertex identifier which define the facet polygon. First + we store the polygon of the first facet of the first cell, then + the second facet of the first cell, until the last facet of the + first cell, followed by the first facet of the second cell, + and so on and so forth. + + + + + + + + A sequence of cell identifier so that each facet is associated + with its cell because of which it is then possible to segment + out cells three-dimensionally based on cell i.e. evaporation_id. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml new file mode 100644 index 000000000..f7e0f3433 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml @@ -0,0 +1,568 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals mapped on this ion type. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Number of ions probed in the combinatorial analysis of the charge states + + + + + Results of a paraprobe-transcoder tool run. + + + + + + Version specifier of this application definition. + + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstruction. The XDMF datatype + is here 1, the number of primitives 1 per triplet, the last integer + in each triplet is the identifier of each point starting from zero. + + + + + + + + + + On a mid term perspective we would like to evolve the paraprobe-toolbox + to an implementation stage where it works exclusively with completely + provenance-tracked formats for both the configuration of the workflow step + and/or analysis with each tool and also for the output of these analyses + in the form of so-called tool-specific results files. + Currently the Hierarchical Data Format 5 (HDF5) is used to store such data. + + Different file formats can be used to inject reconstructed datasets and + ranging definitions into the toolbox. Traditionally, these are the POS, + ePOS, and APT files with the tomographic reconstruction and other metadata + and RNG and RRNG file formats for the ranging definitions how mass-to-charge + state-ratio values map on (molecular) ion types. Such input should be + injected via specific NeXus/HDF5 files which are documented + in compliance with the NXapm application definition. + + So far the paraprobe-toolbox was used as a standalone tool. Therefore, it + was not relevant during the development to focus on interoperability. + Essentially paraprobe-transcoder was used as a parser to transcode data + in the above-mentioned file formats into a paraprobe-specific + representation. This transcoding should become deprecated. + Here we describe steps we have taken into this direction. + + With the work in the FAIRmat project and the desire to make the paraprobe- + toolbox also accessible as a cloud-computing capable service in the Nomad + Remote Tools Hub (NORTH) the topic of interoperability became more important + and eventually the NXapm application definition was proposed. + NORTH is a GUI and related service in a NOMAD OASIS instance which allows + to spawn preconfigured docker containers via JupyterHub. + Currently, NORTH includes the so-called apm container. A container with + tools specific for analyzing data from atom probe microscopy as well as + processing of point cloud and mesh data. + + The NXapm application definition and related implementation work within + NOMAD OASIS enabled users to parse content of POS, ePOS, APT, RNG, and + RRNG files, surplus key metadata from vendor-agnostic electronic lab notebook + solutions directly into NOMAD OASIS via the uploads section. + The process is automated and yields an NXapm-compliant NeXus/HDF5 file + inside the uploads section in return. + + With these improvements made there is no longer a need for - at least the + users of a NOMAD OASIS and NORTH instance to use the deprecated + PARAPROBE.Transcoder.Results.*.h5 files. Ideally, paraprobe should + automatically detect that the input can now be an NXapm-compliant NeXus/HDF5 + file and in response work with this file directly. + To remain compliant with users however who do not have or do not wish + to use a NOMAD OASIS or NXapm or NeXus at all right now, the solution is + as follows: + + Calling the configuration stage of paraprobe-transcoder is always mandatory. + It is always the first step of working with the toolbox. In this process + the user defines the input files. These can either be nxs i.e. the NXapm/NeXus/ + HDF5 file from e.g. the upload section, or such a file that was obtained from + a colleague with a NOMAD OASIS instance. + In all other cases, users can pass the reconstruction and ranging definitions + using the traditional POS, ePOS, or APT and RNG or RRNG file formats respectively. + + Based on which input the user delivers, the parmsetup-transcoder tool then + creates a configuration file PARAPROBE.Transcoder.Config.SimID.*.nxs and + informs the user whether the input was NeXus (and thus if all relevant + input is already available) or whether the paraprobe-transcoder tool needs + to be executed to convert the content of the vendor files first into a + format which paraprobe can provenance track and understand. + In the latter case, the PARAPROBE.Transcoder.Config.SimID.*.nxs file is + used to communicate to all subsequently used tools from which files + the tools can expect to find the reconstruction and ranging definitions. + + All subsequent analysis steps start also with a tool-specific configuration. + This configuration step reads in (among others) the + PARAPROBE.Transcoder.Config.SimID.*.nxs file from which the configuration + tool identifies automatically whether to read the reconstruction and ranging data + from PARAPROBE.Transcoder.Results.SimID.*.h5 or directly the NXapm-compliant + NeXus/HDF5 file that was created upon preparing the upload or the file shared + from a colleague. This design removes the need for unnecessary copies of the data. + Currently still though users should execute the transcoder step as it will + generate a supplementary XDMF topology field with which the data in either + the NeXus/HDF5 or the transcoded vendor files can be displayed using e.g. + Paraview. For this purpose XDMF is used. + + Of course ideally the APT community would at some point converge to use + a common data exchange file format. To this end, AMETEK/Cameca's APT file format + could be a good starting point but so far it is lacking a consistent way of + how to store generalized ranging definitions and post-processing results. + POS, ePOS, Rouen's ATO, as well as other so far used representations of data + like CSV or text files have, to the best of our current knowledge, no + concept of how to marry reconstruction and (optional) ranging data into + one self-descriptive format. + + This summarizes the rationale behind the current choices of the I/O for + paraprobe. Furthermore, this summarizes also why the fundamental design + of splitting an analysis always into steps of configuration (with parmsetup), + task execution (with the respective C/C++ or Python tool of the toolbox), + and post-processing (e.g. with autoreporter) is useful because it offers + a clear description of provenance tracking. This is a necessary step to make + atom probe microscopy data at all better aligned with the aims of the + FAIR principles. + + The internal organization of the data entries in the atom_probe group + in this application definition for paraprobe-transcoder results files + mirror the definitions of the NXapm for consistency reasons. + + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + Details and results of the combinatorial analyses of this + range definition to identify the charge_state for an ion. + + + + Currently charge_state not charge! + + + + + + + + Specific isotopes building each candidate matching the range. + + + + + + + + + Accumulated mass of the isotopes in each candidate. + Not corrected for quantum effects. + + + + + + + + + Product of natural abundance of the isotopes per candidate. + + + + + + + + Filter criterion on the product of the natural abundances + computed from each isotope building the (molecular) ion. + Such a filter can be used to reduce the number of possible + molecular ions considered when trying to find a unique solution + to the question which charge_state does a molecular ion + within a given range and given combination of elements have. + + + + + Filter criterion on the minimum half life which all isotopes + building the (molecular) ion need to have to consider the + candidate. + Such a filter can be used to reduce the number of possible + molecular ions considered when trying to find a unique solution + to the question which charge_state does a molecular ion + within a given range and given combination of elements have. + + + + + + If the value is zero/false it means that non-unique solutions + are accepted. These are solutions where multiple candidates + differ in their isotopes but have the same charge. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml deleted file mode 100644 index 89484faa9..000000000 --- a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml +++ /dev/null @@ -1,125 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Application definition for a configuration file of the paraprobe-selector tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml deleted file mode 100644 index 563029178..000000000 --- a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - Application definition for results files of the paraprobe-selector tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The purpose and need of the paraprobe-selector tool is to identify which reconstructed positions - are located inside or on the surface of a (possibly complicated) region-of-interest (ROI). - In addition, the tool allows to filter ions for properties. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml deleted file mode 100644 index 5f4b26836..000000000 --- a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml +++ /dev/null @@ -1,338 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms per molecular ion. Should be 32 for paraprobe. - - - - - Number of different source iontypes to distinguish. - - - - - Number of different target iontypes to distinguish. - - - - - Application definition for a configuration file of the paraprobe-spatstat tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. - - - - - - - - - - - How many spatial_statistics tasks should the tool execute. - - - - - - - - - - - - - - - - - - - - - - - Distance between each ion and triangulated surface mesh. - - - - - - - - - Threshold to define how far an ion has to lay at least from the edge - of the dataset so that the ion can act as a source. This means that - an ROI is placed at the location of the ion and its neighbors are - analyzed how they contribute to the computed statistics. - - The edge_distance threshold can be combined with the feature_distance threshold. This threshold defines defines up to which distance to a - microstructural feature an ROI is placed. - - The threshold is useful to process the dataset such that ROIs do - not protrude out of the dataset as this would add bias. - - - - - - Distance between each ion and triangulated mesh of microstructural features. - In addition to spatial filtering and considering how far ions lie to the - edge of the dataset, it is possible to restrict the analyses to a sub-set of - ions within a distance not farther away to a feature than the feature_distance - threshold value. - - - - - - - - Absolute path in the (HDF5) file which points to the distance of each - ion to the closest feature. - - - - - Threshold to define how close an ion has to lay to a feature so that - the ion can at all qualify as a source, i.e. that an ROI is placed - at the location of the ion and its neighbors are then analyzed - how they contribute to the computed statistics. - - Recall that this feature_distance threshold is used in combination - with the edge_distance threshold when placing ROI about source ions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specifies, if the iontypes are randomized for the point cloud or not. - Internally, paraprobe uses a sequentially executed deterministic MT19987 - (MersenneTwister) pseudo-random number generator to shuffle the - iontypes randomly across the entire set of ions. That is the total - number of ions of either type remain the same but the information about - their location is randomized. - - - - - - - - - - How should the iontype be interpreted on the source-side, i.e. - all these ion positions where a regions-of-interest (ROI) around - so-called source ions will be placed. Different options exist - how iontypes are interpreted given an iontype represents - in general a (molecular) ion with different isotopes that have - individually different multiplicity. - - The value resolve_all will set an ion active in the analysis regardless - of which iontype it is. Each active ion is accounted for once. - - The value resolve_unknown will set an ion active when the ion is - of the UNKNOWNTYPE type. Each active ion is accounted for once. - - The value resolve_ion will set an ion active if it is of the specific - iontype, irregardless of its elemental or isotopic details. - Each active ion is counted once. - - The value resolve_element will set an ion active, and most importantly, - account for each as many times as the (molecular) ion contains - atoms of elements in the whitelist ion_query_isotope_vector. - - The value resolve_isotope will set an ion active, and most importantly, - account for each as many times as the (molecular) ion contains - isotopes in the whitelist ion_query_isotope_vector. - - In effect, ion_query_isotope_vector acts as a whitelist to filter - which ions are considered as source ions of the correlation statistics - and how the multiplicity of each ion will be factorized, i.e. how - often it is accounted for. - - - - - - - - - - - - Matrix of isotope vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - Combined with ion_query_type_source set to resolve_element this will - recover usual spatial correlation statistics like the 1NN C-C - spatial statistics. - - - - - - - - - Similarly as ion_query_type_source how should iontypes be interpreted - on the target-side, i.e. how many counts will be bookkept for ions - which are neighbors of source ions within or on the surface of each - inspection/ROI about each source ion. - Source ion in the center of the ROI are not accounted for during - counting the summary statistics. - For details about the resolve values consider the explanations in - ion_query_type_source. These account for ion_query_type_target as well. - - - - - - - - - - - - - Matrix of isotope vectors, as many as rows as different candidates for - iontypes to distinguish as possible targets. See additional comments - under ion_query_isotope_vector_source. - - - - - - - - - Specifies which spatial statistics to compute. - - - - Compute k-th nearest neighbour statistics. - - - - Order k. - - - - - Minimum value, increment, and maximum value of the histogram binning. - - - - - - - - - Compute radial distribution function. - - - - Minimum value, increment, and maximum value of the histogram binning. - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml deleted file mode 100644 index 52187c951..000000000 --- a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml +++ /dev/null @@ -1,200 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - The total number of bins in the histogram for the k-th nearest neighbor. - - - - - The total number of bins in the histogram for the radial distribution function. - - - - - Application definition for results files of the paraprobe-spatstat tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - - - - - - - - - - - - - - - - - - - The iontype ID for each ion that was assigned to each ion during - the randomization of the ionlabels. Iontype labels are just permuted - but the total number of values for each iontype remain the same. - - The order matches the iontypes array from a given ranging results - as it is specified in the configuration settings inside the specific - config_filename that was used for this paraprobe-spatstat analysis. - - - - - - - - K-nearest neighbor statistics. - - - - Right boundary of the binning. - - - - - - - - - - - - - Cumulated not normalized by total counts. - - - - - - - - Cumulated and normalized by total counts. - - - - - - - - - Radial distribution statistics. - - - - Right boundary of the binning. - - - - - - - - - - - - - Cumulated not normalized by total counts. - - - - - - - - Cumulated and normalized by total counts. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml deleted file mode 100644 index 3cb04dac6..000000000 --- a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml +++ /dev/null @@ -1,235 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of alpha values (and offset values) to probe. - - - - - How many different match values does the filter specify. - - - - - Application definition for a configuration file of the paraprobe-surfacer tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specifies the method that is used to preprocess the point cloud - prior to the alpha-shape computation. - - The option *default* specifies that no such filtering is applied. - The option *kuehbach* specifies that a Hoshen-Kopelman - percolation analysis is used to identify points that lie closer - to the edge of the dataset. Details about the methods are reported - in `M. Kühbach et al. <https://doi.org/10.1038/s41524-020-00486-1>`_. - - - - - - - - - When using the kuehbach preprocessing, this is the width of the - kernel for identifying which ions are in voxels close to the - edge of the point cloud. - - - - - - Specifies which method to use to define the alpha value. - - The value *convex_hull_naive* is the default. The setting instructs - the tool to use a fast specialized algorithm for computing only - the convex hull. The resulting triangles can be skinny. - - The value *convex_hull_refine* instructs to tool to refine the - quality of the mesh resulting from *convex_hull_naive* - via triangle flipping and splitting. - - The value *smallest_solid* instructs the CGAL library to choose a - value which realizes an alpha-shape that is the smallest solid. - - The value *cgal_optimal* instructs the CGAL library to choose a - value which the library considers as to be an optimal value. - Details are defined in the respective section of the CGAL library - on 3D alpha shapes. - - The value *set_of_values* instructs the tool to compute a list - collection of alpha-shapes for the specified alpha-values. - - The value *set_of_alpha_wrappings* instructs the tool to generate - a set of so-called alpha wrappings. These are similar to alpha-shapes - but provide additional guarantees (such as watertightness and - proximity constraints) on the resulting wrapping. - - - - - - - - - - - - - Array of alpha values to use when alpha_value_choice is - set_of_values or when alpha_value_choice is set_of_alpha_wrappings. - - - - - - - - Array of offset values to use when alpha_value_choice is set_of_alpha_wrappings. - The array of alpha_values and offset_values define a sequence of (alpha and offset value). - - - - - - - - Specifies if the tool should compute the set of exterior triangle facets - for each alpha complex (for convex hull, alpha shapes, and wrappings). - - - - - Specifies if the tool should check if the alpha complex of - exterior triangular facets is a closed polyhedron. - - - - - Specifies if the tool should compute all interior tetrahedra - of the alpha complex (currently only for alpha shapes). - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml deleted file mode 100644 index fa2bbd882..000000000 --- a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml +++ /dev/null @@ -1,289 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - The number of vertices of the alpha complex. - - - - - The number of faces of the alpha complex. - - - - - The total number of XDMF values to represent all faces of triangles via XDMF. - - - - - The total number of XDMF values to represent all faces of tetrahedra via XDMF. - - - - - Application definition for results files of the paraprobe-surfacer tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The purpose and need of the paraprobe-surfacer tool is the generation of meshed - representation of the surface of the the reconstructed volume (or a portion) of it - using different algorithms from the computational geometry community. - - - - - - - - - - - - Paraprobe-surfacer can be used to load a ROI that is the entire or a - sub-set of the ion point cloud. In the point_cloud_wrapping process - the tool computes a triangulated surface mesh which encloses the - ROI/point cloud. This mesh can be seen as a model for the edge of - the dataset. - - Different algorithms can be used with paraprobe-surfacer to create - this mesh such as convex hulls, alpha-shapes as their generalization, - or alpha wrappings. - - Ideally, the resulting mesh should be a watertight polyhedron. - This polyhedron is not necessarily convex. For some algorithms there - is no guarantee that the resulting mesh yields a watertight mesh. - - - - - - - - - - - - - A bitmask which identifies exactly all those ions whose positions - were considered when defining the filtered point set from which - that alpha_complex instance was computed. - - This window can be different to the window of the *point_set_wrapping* - parent group because irrelevant ions might have been filtered out in addition - to the window defined in *point_set_wrapping* to reduce e.g. computational - costs of the alpha complex computation. - - - - - Number of ions covered by the mask. - - - - - Number of bits assumed matching on a default datatype. - - - - - The bitfield of the mask. See :ref:`NXcs_filter_boolean_mask` for - how this bitfield is to be interpreted. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The set of triangles in the coordinate system paraprobe - which discretizes the exterior surface of the alpha complex. - - - - - - - - - - - - - - - - - - - - - - - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tri * (1+1+3). - - - - - - - - Do the triangles define a triangulated surface mesh that is watertight? - - - - - The volume which the triangulated surface mesh - encloses if that mesh is watertight. - - - - - - - The set of tetrahedra which represent the interior volume - of the complex if that is a closed two-manifold. - - - - - The accumulated volume of all interior tetrahedra. - - - - - - - - - - - - - - - - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tet * (1+1+4). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml deleted file mode 100644 index bf9125651..000000000 --- a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - Application definition for a configuration file of the paraprobe-tessellator tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The method used to compute the tessellation. - The value *default* configures the computation of the Voronoi tessellation. - - - - - - - - - Specifies if the tool should report the volume of each cell. - - - - - Specifies if the tool should report the first-order neighbors of each cell. - - - - - Specifies if the tool should report the facets and vertices of each cell. - - - - - Specifies if the tool should report for each cell if it makes contact with - the tight axis-aligned bounding box about the point cloud. - This can be used to identify if the shape of the cell is likely affected - by the edge of the dataset or if cells are deeply enough embedded - into the point cloud so that the shape of their cells are not affected - anymore by the boundary. This is valuable information to judge - about the significance of finite size effects. - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml deleted file mode 100644 index dbfa7dc94..000000000 --- a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml +++ /dev/null @@ -1,337 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - The total number of values required to represent all faces of each cell. - - - - - The total number of values required to represent all faces of each cell - (polyhedron) using XDMF. - - - - - Application definition for results files of the paraprobe-tessellator tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - - - - - - - - - - - - The tool can be used to compute a Voronoi tessellation the entire - or of a sub-set of the reconstructed volume. Each point (ion) is wrapped - in one (Voronoi) cell. The point cloud in the ROI is wrapped into an - axis-aligned bounding box (AABB) that is tight. This means points at - the edge of the point cloud can lay on the surface of the bounding box. - The tool detects if cells make contact with the walls of this bounding box. - The tessellation is computed without periodic boundary conditions. - - - - - - - - - - - The (tight) axis-aligned bounding box about the point cloud. - - - - Coordinate triplet of the corner that lays closests - to the origin of the *paraprobe* coordinate system. - - - - - - - - Coordinate triplet of the corner that lays farthest away - from the origin of the *paraprobe* coordinate system. - - - - - - - - - - - - - - - The number of points (and thus cells). - - - - - Volume of each Voronoi cell. - - - - - - - - Which MPI process computed which Voronoi cell. - - - - - - - - Which OpenMP thread computed which Voronoi cell. - - - - - - - - The number of faces for each cell. Faces of adjoining polyhedra are counted - for each polyhedron. This field can be used to interpret the concatenated vector - with the individual values for the area of each face. - - - - - - - - - A simple approach to describe the entire set of polyhedra when the main - intention is to store the shape of the polyhedra for visualization purposes. - - - - - - - - - - Sequence of tuples, concatenated in the order of the Voronoi cells. - Each tuple contains encodes information to visualize using XDMF: - Firstly, an XDMF geometric primitive type key. - Secondly, the number of vertices of the polygon. - Third, the sequence of vertex identifier which define the facet. - Tuples encode faces faster than cells. - - - - - - - - Sequence of cell identifier, concatenated such that each face is - associated with its cell. Given that paraprobe-tessellator assigns - each cell the evaporation_id of the ion that the cell wraps this - information enables the segmentation of the tessellation and - thus correlate per-ion properties with the volume that each cell - represents. - - - - - - - - - A bitmask that documents which of the cells are likely truncated because they - share at least one face with the *aabb* of the point cloud. This field encodes the - result of the boolean or operator applied to the value of all six wall_contact groups - that document contact in specific outer unit normal directions of the *aabb*. - - - - - - - - - - - - - In the spirit of wall_contact_global, the left face of *aabb*. - Its outer unit normal points in the opposite direction of the - x-axis of the *paraprobe* coordinate system. - - - - - - - - - - - - In the spirit of wall_contact_global, the right face of *aabb*. - Its outer unit normal points in the direction of the x-axis - of the *paraprobe* coordinate system. - - - - - - - - - - - - In the spirit of wall_contact_global, the front face of *aabb*. - Its outer unit normal points in the opposite direction of the - y-axis of the *paraprobe* coordinate system. - - - - - - - - - - - - In the spirit of wall_contact_global, the rear face of *aabb*. - Its outer unit normal points in the direction of the y-axis - of the *paraprobe* coordinate system. - - - - - - - - - - - - In the spirit of wall_contact_global, the front face of *aabb*. - Its outer unit normal points in the opposite direction of the - z-axis of the *paraprobe* coordinate system. - - - - - - - - - - - - In the spirit of wall_contact_global, the front face of *aabb*. - Its outer unit normal points in the direction of the z-axis of the - *paraprobe* coordinate system. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml deleted file mode 100644 index 541a059a7..000000000 --- a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml +++ /dev/null @@ -1,129 +0,0 @@ - - - - - - Base class documenting the information common to tools of the paraprobe-toolbox. - - The paraprobe-toolbox is a collection of open-source tools for performing - efficient analyses of point cloud data where each point can represent atoms or - (molecular) ions. A key application of the toolbox has been for research in the - field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): - - * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ - * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ - - The toolbox does not replace but complements existent software tools in this - research field. Given its capabilities of handling points as objects with - properties and enabling analyses of the spatial arrangement of and inter- - sections between geometric primitives, the software can equally be used - for analyzing data in Materials Science and Materials Engineering. - - The common section can be used as a place to store e.g. organizational - metadata and contextualization of that analysis in a research data - management system. - - - - A statement whether the tool executable managed to process the analysis - or whether this failed. Status is written to the results file after the - end_time beyond which point in time the tool must no longer compute - any further analysis results but exit. - - Only when this status message is present and its value is `success`, - one should consider the results of the tool. In all other cases it might - be that the tool has terminated prematurely or another error occurred. - - - - - - - - - - - Internal identifier used by the tool to refer to an analysis (aka simulation - id). - - - - - The configuration file that was used to parameterize - the algorithms that this tool has executed. - - - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis in this results file was started, - i.e. when the respective executable/tool was started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis in this results file were - completed and the respective process of the tool exited. - - - - - Wall-clock time. - - - - - - - Details about coordinate systems (reference frames) used. In atom probe several coordinate - systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` - should be documented explicitly and doing so by picking from the - following controlled set of names: - - * paraprobe - * lab - * specimen - * laser - * instrument - * detector - * recon - - The aim of this convention is to support users with contextualizing which reference frame - each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` - are used to detail the explicit affine transformations whereby one can convert - representations between different reference frames. - Inspect :ref:`NXtransformations` for further details. - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml deleted file mode 100644 index c2169cc13..000000000 --- a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml +++ /dev/null @@ -1,137 +0,0 @@ - - - - - - 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. - - - - - - 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. - - - - - - Specification of the triangulated surface mesh to use for this analysis. - - Such a surface mesh can be used to define the edge of the reconstructed - volume to account for finite size effects. - - - - - - Specification of the point-to-triangulated-surface-mesh distances to - use for this analysis. - - - - Absolute path in the (HDF5) file that points to the distance values. - The tool assumes that the values are stored in the same order as - points (ions). - - - - - - - - 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 2ac82f751..000000000 --- a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml +++ /dev/null @@ -1,87 +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). - - The paraprobe coordinate system is the reference *NXcoordinate_system* - for each geometric primitive. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - A bitmask which identifies all ions considered in the analysis. - - - - Number of ions covered by the mask. - By default, the total number of ions in the dataset. - - - - - Number of bits assumed matching on a default datatype. - - - - - The mask. The length of the mask is an integer multiple of bitdepth. - In such case, padded bits are set to 0. - - - - - - - - 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 21b882cc6..000000000 --- a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml +++ /dev/null @@ -1,83 +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. - - - - - - - - - - - - - - - - - - - - - - - - Specification of the ranging definition file to use for this analysis. - - - - - - - - - - - - - - - - - - - - - - - - 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 3153d9558..000000000 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ /dev/null @@ -1,219 +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. - - - - - Number of entries - - - - - Application definition for results files of the paraprobe-transcoder tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The purpose and need of the paraprobe-transcoder tool is to create a standardized representation - of reconstructed position and mass-to-charge-state-ratio values surplus other pieces of information - to enable working with atom probe data in reconstruction space in the paraprobe-toolbox. - This includes ranging definitions which map mass-to-charge-state ratio values onto iontypes. - - So far the atom probe community has not yet agreed upon a comprehensive standardization on how to - exchange information especially when it comes to the communication of configurations and results - from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS, ePOS, - APT, or RNG and RRNG. None of these formats, though, are self-descriptive, standardize, or document - their origin and thus the sequence in which the file was generated during an analysis. - - Paraprobe-transcoder solves this limitation by interpreting the information content in such files - and standardize the representation prior injection into the scientific data analysis tools of the toolbox. - Therefore, the here proposed set of NeXus base classes and application definitions can be a useful - starting point for the atom probe community to take advantage of standardized information - exchange and improve the here proposed classes and concepts to become more inclusive. - - Paraprobe-transcoder uses a Python library developed based on efforts by members of the - global atom probe community `International Field Emission Society (IFES) Atom Probe Technical Committee (APT TC) <https://www.github.com/atomprobe-tc/ifes_apt_tc_data_modeling>`_. This library offers the - actual low-level I/O operations and respective information interpretation of above-mentioned file formats. - - - - - - - - - - - - - - - - - - - - - By default the entire reconstructed volume is processed. - In this case, using window is also equivalent to an - NXspatial_filter that specified a window *entire_dataset*. - - - - - - - - - - Mass-to-charge-state-ratio values. - - - - - - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - Defines in which reference frame the positions are defined. - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstruction. The XDMF datatype - is here 1, the number of primitives 1 per triplet, the last integer - in each triplet is the identifier of each point starting from zero. - - - - - - - - - - - Details about how peaks are interpreted as ion types or not. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXatom_set.nxdl.xml b/contributed_definitions/NXatom_set.nxdl.xml deleted file mode 100644 index 0a1e20856..000000000 --- a/contributed_definitions/NXatom_set.nxdl.xml +++ /dev/null @@ -1,158 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Base class for documenting a set of atoms. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. - - The identifier zero is reserved for the special unknown ion type. - - - - - Vector of nuclide hash values. - - Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` - encode the number of protons :math:`Z` and the number of neutrons :math:`N` - of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. - - The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. - The first column specifies the nuclide mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no - isotope-specific information about the element encoded is relevant. - The second row specifies the number of protons :math:`Z` or 0. - The value 0 in this case documents a placeholder or that no element-specific - information is relevant. - Taking a carbon-14 nuclide as an example the mass number is 14. - That is encoded as a value pair (14, 6) as one row of the table. - - Therefore, this notation is the typical superscribed nuclide mass number - and subscripted number of protons element notation e.g. :math:`^{14}C`. - The array is stored matching the order of nuclide_hash. - - - - - - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored alongside ranging - definitions. - - - - - Charge of the ion. - - - - - Signed charge state if the atoms form an ion reported in multiples of electron charge. - - In the example of atom probe microscopy, only positive values will be measured - as the ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, the value should - be set to zero. - - In atom probe microscopy this is for example the case when using - classical ranging definition files in formats like RNG, RRNG. - These file formats do not document the charge state explicitly - but the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - Details on ranging definition files can be found in the literature: - `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable name (e.g. Al +++) of the atom set, the atom group, or ion type. - The string should consists of UTF-8 characters, ideally using LaTeX - notation to specify the isotopes, ions, and charge state. - Examples are 12C + or Al +++. - - To ease automated parsing, isotope_vector should be the - preferred machine-readable information used. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of the - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries inclusive). This field is primarily of interest - for documenting :ref:`NXprocess` steps of indexing a - ToF/mass-to-charge state histogram. - - - - - - - diff --git a/contributed_definitions/NXbias_spectroscopy.nxdl.xml b/contributed_definitions/NXbias_spectroscopy.nxdl.xml deleted file mode 100644 index ad484c806..000000000 --- a/contributed_definitions/NXbias_spectroscopy.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - Base classes definition for bias spectroscopy. - - Bias sweeps while measuring arbitrary channels with I(V) curves. - - - - Select the channels to record. - - - - - If chosen, the Bias voltage resets to its initial value (before the sweep initiation) at - the conclusion of the spectroscopy measurement. When this option is not selected, the Bias - voltage maintains the last value acquired during the sweep. This functionality proves - beneficial, especially when combining multiple sweep segments. As an illustration of an - automated measurement: turn off the z-Controller, commence spectroscopy sweep segments ( - forward sweep only, without resetting the bias), restore the bias to its initial value, - and then turn on the z-Controller. - - - - - Select whether to record the Z position during Z averaging time at the end of - the sweep (after Z control time) and store the average value in the header of - the file when saving. Using this option increases the sweep time by Z averaging - time. - - - - - Select whether to set the Lock-In to run during the measurement. When using this - feature, make sure the Lock-In is configured correctly and settling times are - set to twice the Lock-In period at least. This option is ignored when Lock-In is - already running. This option is disabled if the Sweep Mode is MLS and the flag - to configure the Lock-In per segment in the Multiline segment editor is set. - - - - - Time during which the spectroscopy data are acquired and averaged. - - - - - Number of sweeps to measure and average. - - - - - The first bias values of the sweep. - - - - - The last bias values of the sweep. - - - - - Define the sweep number of points, that is, the maximum spectrum resolution eq. - Bias window divide by Num Pixel. - - - - - Duration over which the Z position is recorded and averaged before and after the - sweep (the latter only if Record final Z position is selected in the Advanced - section). After the initial z averaging time, if Z-Controller to Hold is - selected in the Advanced section, the z-Controller is set to hold and the tip is - placed at the previously averaged z position (plus z offset). - - - - - Select a filter to smooth the displayed data. When saving, if any filter is selected, - filtered data are saved to file along with the unfiltered data. - - - - - Filter order of a dynamic filter or width (in number of points) for the Gaussian - filter. - - - - - Cutoff frequency for dynamic filters. - - - - - Offset added to the initial averaged position Zaver before starting to sweep. - This parameter is disabled when Z-Controller to Hold is deselected in the - Advanced section. The LED “Alt” next to the Z offset indicates if an alternate - Z-controller setpoint is enabled. - - - - - Time to wait after changing the bias to the next level and before - starting to acquire data. - - - - - No doc yet. - - - - - Time to wait after the sweep has finished and the bias is ramped to - the initial value. - - - - - Time during which the Z-Controller is enabled once a sweep has finished. - When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled - for this duration between each sweep. After the last sweep, it will wait the - specified time before continuing a running scan. This ensures each sweep - reliably starts from the same position. This parameter is disabled when - Z-Controller to Hold is deselected in the Advanced section. - - - - - Maximum rate at which the bias changes (before, during and after sweeping). - (V/s) - - - - - Select whether to measure the backward (return) sweep or the forward only. - - - - - Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. - It is selected by default. When deselected, Z-offset and Z control time parameters - are disabled. - - - 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/base_classes/NXcg_alpha_complex.nxdl.xml b/contributed_definitions/NXcg_alpha_complex.nxdl.xml similarity index 57% rename from base_classes/NXcg_alpha_complex.nxdl.xml rename to contributed_definitions/NXcg_alpha_complex.nxdl.xml index b6a466bc5..1b3e3446e 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/contributed_definitions/NXcg_alpha_complex.nxdl.xml @@ -1,10 +1,10 @@ - + - - + + + + + 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 of alpha shapes or alpha wrappings about primitives. + Computational geometry description of alpha shapes or wrappings to primitives. For details see: @@ -33,17 +60,22 @@ The so-called spectrum or sets of (weighted) alpha shapes includes the convex hu * 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/Manual/packages.html#PkgAlphaWrap3 for 3D wrap in CGAL, the Computational Geometry Algorithms Library. As a starting point, we follow the conventions of the CGAL library. + + + + + + - 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. + 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. @@ -51,72 +83,69 @@ 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. + Specifically when computed with the CGAL, the mode specifies if singular + faces are removed (regularized) of the alpha complex. + + + + + - - The alpha parameter, i.e. the radius of the alpha-sphere that - is used when computing the alpha complex. + The alpha, (radius of the alpha-sphere) parameter to be used for alpha + shapes and alpha wrappings. - - The offset distance parameter used when computing alpha_wrappings. + The offset distance parameter to be used in addition to alpha + in the case of alpha_wrapping. - - + - Point cloud for which the alpha shape or wrapping has been computed. + Point cloud for which the alpha shape or wrapping should be computed. - + - Triangle soup for which the alpha wrapping has been computed. + Triangle soup for which the alpha wrapping should be computed. - + - Triangle mesh representing the alpha complex. + A meshed representation of the resulting shape. - - - - Set of tetrahedra representing the volume inside the alpha complex. - - + diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml similarity index 51% rename from base_classes/NXcg_cylinder_set.nxdl.xml rename to contributed_definitions/NXcg_cylinder_set.nxdl.xml index e5bb83807..e5e5e8860 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/contributed_definitions/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. + + + + + + + + + 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. - - + - 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/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/base_classes/NXcg_geodesic_mesh.nxdl.xml b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml similarity index 58% rename from base_classes/NXcg_geodesic_mesh.nxdl.xml rename to contributed_definitions/NXcg_geodesic_mesh.nxdl.xml index 6314db342..1b69e9bc4 100644 --- a/base_classes/NXcg_geodesic_mesh.nxdl.xml +++ b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -30,26 +30,28 @@ 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. + 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. - 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>`_ + 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.: - 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. + * `E. S. Popko and C. J. Kitrick <https://doi.org/10.1201/9781003134114>`_ - 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. + Here, especially the section on subdivision schemes is relevant. + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + diff --git a/base_classes/NXcg_grid.nxdl.xml b/contributed_definitions/NXcg_grid.nxdl.xml similarity index 60% rename from base_classes/NXcg_grid.nxdl.xml rename to contributed_definitions/NXcg_grid.nxdl.xml index c83d817d8..f3cbc2853 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/contributed_definitions/NXcg_grid.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,35 +33,36 @@ - The cardinality or total number of cells aka grid points. + The cardinality or total number of cells/grid points. - Number of boundaries of the bounding box or primitive housing the grid. + Number of boundaries of the bounding box or primitive to the grid. - Computational geometry description of a grid of Wigner-Seitz cells in Euclidean space. + Computational geometry description of a Wigner-Seitz cell grid 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. + 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. - - - 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. @@ -77,23 +78,49 @@ - + 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. @@ -114,25 +141,24 @@ should constraints on the grid be place here or not--> - A tight bounding box about the grid. + A tight bounding box or sphere or bounding primitive about the grid. - - + - Number of boundaries distinguished - + How many distinct boundaries are distinguished? Most grids discretize a cubic or cuboidal region. In this case six sides can be distinguished, each making an own boundary. - + - Name of 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/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml similarity index 62% rename from base_classes/NXcg_half_edge_data_structure.nxdl.xml rename to contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml index 759e30943..81c66fb2b 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml @@ -1,10 +1,10 @@ - + - + @@ -54,63 +54,41 @@ Such a data structure can be used to efficiently circulate around faces and iterate over vertices of a planar graph. - - - - Number of vertices for each face. - - Each entry represents the total number of vertices for that face, - irrespectively whether vertices are shared among faces or not. - - - - - - - - Number of edges for each face. - - Each entry represents the total number of edges for that face, - irrespectively whether edges are shared across faces or not. - - - - - - - - Number of faces of the primitives. - - + + + + - Integer offset whereby the identifier of the first member - of the vertices differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of :ref:`NXcg_primitive_set` for further details. + 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 edges differs from zero. + 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. - Identifier can be defined explicitly or implicitly. - Inspect the definition of :ref:`NXcg_primitive_set` for further details. + The face identifier zero is reserved for the NULL face ! - + - 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. + In this half-edge data structure half-edge identifiers start at 1. + Half-edges are identified with consecutive integers up to number_of_half_edges. + This field can be used to document which constant integer has to be + added to another set of half_edge_identifier to assure that these other + identifiers also start at 1. - + The position of the vertices. @@ -119,7 +97,7 @@ - + Identifier of the incident half-edge. @@ -127,7 +105,7 @@ - + Identifier of the (starting)/associated half-edge of the face. @@ -135,7 +113,7 @@ - + The identifier of the vertex from which this half-edge is outwards pointing. @@ -143,7 +121,7 @@ - + Identifier of the associated oppositely pointing half-edge. @@ -151,7 +129,7 @@ - + If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. @@ -160,7 +138,7 @@ - + Identifier of the next half-edge. @@ -168,7 +146,7 @@ - + Identifier of the previous half-edge. @@ -176,14 +154,14 @@ - + 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/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/base_classes/NXcg_marching_cubes.nxdl.xml b/contributed_definitions/NXcg_marching_cubes.nxdl.xml similarity index 54% rename from base_classes/NXcg_marching_cubes.nxdl.xml rename to contributed_definitions/NXcg_marching_cubes.nxdl.xml index b1f6310dd..b1f8e9273 100644 --- a/base_classes/NXcg_marching_cubes.nxdl.xml +++ b/contributed_definitions/NXcg_marching_cubes.nxdl.xml @@ -1,10 +1,10 @@ - + - - + + + + 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 can help to understand 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>`_ - * `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. + Commercial or otherwise given name to the program which was used. + + + Program version plus build number, commit hash, or description of + an ever persistent resource where the source code of the program + and build instructions can be found so that the program can be + configured in such a manner that the result file is ideally + recreatable yielding the same results. + + - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 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/base_classes/NXcg_polyline_set.nxdl.xml b/contributed_definitions/NXcg_polyline_set.nxdl.xml similarity index 51% rename from base_classes/NXcg_polyline_set.nxdl.xml rename to contributed_definitions/NXcg_polyline_set.nxdl.xml index f57d0c53f..b64c3467d 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyline_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -50,29 +50,58 @@ multiple vertices possible with the same point coordinates but different names.- - Computational geometry description of a set of polylines. + Computational geometry description of a set of polylines in Euclidean space. Each polyline is built from a sequence of vertices (points with identifiers). Each polyline must have a start and an end point. - The sequence describes the positive traversal along the polyline when - walking from the first to the last vertex. + The sequence describes the positive traversal along the polyline when walking + from the start vertex to the end/last vertex. - + + + + - The total number of vertices that have different positions. + 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. - + - The total number of vertices, irrespective of their eventual uniqueness. + 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 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. + Reference to or definition of a coordinate system with + which the qualifiers and polyline data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + polylines. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polylines for explicit indexing. @@ -82,57 +111,73 @@ 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 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. + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. - If true indicates that the vertices are all placed at different positions and have different identifiers, i.e. no points overlap - or are counted several times. + or are counted twice. - Sequence of identifier for vertices how they build each polyline. + Sequence of vertex identifiers which describe each polyline. A trivial example is a set with two polylines with three vertices each. If the polylines meet in a junction, say the second vertex is shared and marking the junction between the two polylines, it is possible that - there are only five unique positions. This suggests to store five - unique vertices. + there are only five unique positions suggesting five unique vertices. - A non-trivial example is a set with several polylines. Assume that each - has a different number of vertices. The array stores the identifier of - the vertices in the sequence how the polylines are visited: + A non-trivial example is a set with several polylines, each of which with + eventually different number of vertices. The array stores the vertex + identifiers in the order how the polylines are visited: - The first entry is the identifier of the first vertex of the first polyline, + The first entry is the identifier of the start vertex of the first polyline, followed by the second vertex of the first polyline, until the last vertex - of the 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: + of the polyline. Thereafter, the start vertex of the second polyline, and + so on and so forth. Using the (cumulated) counts in number_of_vertices, + the vertices of the n-th polyline can be accessed on the following + array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. + + + + The length of each polyline. + + + + + + + + If true specifies that a polyline is closed, i.e. + its end point is connected to the start point. + + + + + + + diff --git a/contributed_definitions/NXcg_roi_set.nxdl.xml b/contributed_definitions/NXcg_roi_set.nxdl.xml new file mode 100644 index 000000000..ab2b67775 --- /dev/null +++ b/contributed_definitions/NXcg_roi_set.nxdl.xml @@ -0,0 +1,40 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Base class to hold geometric primitives. + + + + + + + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml new file mode 100644 index 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/base_classes/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml similarity index 50% rename from base_classes/NXcg_ellipsoid_set.nxdl.xml rename to contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml index e22a677c1..51ec02bfd 100644 --- a/base_classes/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangulated_surface_mesh.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. - - - Computational geometry description of a set of ellipsoids. + Computational geometry description of a mesh of triangles. + + The mesh may be self-intersecting and have holes but the + triangles must not be degenerated. - - - Radius of the half axes. - - Use if all ellipsoids in the set have the same half-axes. - - - - - - + + + - Half-axes radii of each ellipsoid. + A graph-based approach to describe the mesh when it is also desired + to perform topological processing or analyses on the mesh. - - - - - - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml similarity index 71% rename from base_classes/NXcg_unit_normal_set.nxdl.xml rename to contributed_definitions/NXcg_unit_normal_set.nxdl.xml index 21470b34f..68f9c847e 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml @@ -1,10 +1,10 @@ - + - - - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -44,14 +42,12 @@ 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 - a unit normal. + Direction of each normal @@ -60,13 +56,12 @@ rather make this a set of vectors, irrespective whether these are unit or not--> - 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. + Qualifier how which specifically oriented normal to its primitive each + normal represents. * 0 - undefined - * 1 - outer unit normal vector - * 2 - inner unit normal vector + * 1 - outer + * 2 - inner diff --git a/base_classes/NXchamber.nxdl.xml b/contributed_definitions/NXchamber.nxdl.xml similarity index 76% rename from base_classes/NXchamber.nxdl.xml rename to contributed_definitions/NXchamber.nxdl.xml index f6cbac913..edf318e2a 100644 --- a/base_classes/NXchamber.nxdl.xml +++ b/contributed_definitions/NXchamber.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Base class for a chamber in an instrument that stores real or simulated objects. + Component of an instrument to store or place objects and specimens. - + - Given name for the chamber of this component e.g. analysis chamber - or buffer chamber, load-lock chamber, microscope column, glove box. + 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/contributed_definitions/NXchemical_composition.nxdl.xml similarity index 100% rename from base_classes/NXchemical_composition.nxdl.xml rename to contributed_definitions/NXchemical_composition.nxdl.xml diff --git a/contributed_definitions/NXcircuit_board.nxdl.xml b/contributed_definitions/NXcircuit_board.nxdl.xml new file mode 100644 index 000000000..4e64e65bc --- /dev/null +++ b/contributed_definitions/NXcircuit_board.nxdl.xml @@ -0,0 +1,45 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Circuit board with e.g. ADC and/or DAC electronic components. + + Currently used to store the settings of the so-called magboards used in + Nion electron microscopes but likely this could be a useful base class for + substantially more use cases where details at a deep technical instrument design + level are relevant or important. + + + + TBD by Nion Co. + + + + + diff --git a/contributed_definitions/NXclustering.nxdl.xml b/contributed_definitions/NXclustering.nxdl.xml new file mode 100644 index 000000000..76351758d --- /dev/null +++ b/contributed_definitions/NXclustering.nxdl.xml @@ -0,0 +1,124 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of numeral labels per object. + + + + + Number of categorical labels per object. + + + + + Total number of clusters detected. + + + + + Metadata to the results of a clustering analysis. + + Clustering algorithms are routine tools to segment a set of objects/primitives + into groups, objects of different type. A plethora of algorithms have been + proposed for geometric primitives as objects, such as points, triangles, + or (abstract) objects. + + This base class considers metadata and results of one clustering + applied to a set in which objects are either categorized as noise + or belonging to a cluster, specifically here only one cluster. + + + + How many numeric labels does each object have. + + + + + How many categorical labels does each object have. + + + + + Reference to a set of objects investigated in a cluster analysis. + Objects must have clear integer identifier. + + + + + Reference to numeric attribute data for each object. + + + + + Reference to categorical attribute data for each object. + + + + + + Which identifier is the first to be used to label a cluster. + + The value should be chosen in such a way that special values can be resolved: + * identifier_offset-1 indicates an object belongs to no cluster. + * identifier_offset-2 indicates an object belongs to the noise category. + Setting for instance identifier_offset to 1 recovers the commonly used + case that objects of the noise category get values to -1 and unassigned points to 0. + + + + + Total number of objects categorized as unassigned. + + + + + Total number of objects categorized as noise. + + + + + Total number of clusters (excluding noise and unassigned). + + + + + Number of objects associated to each cluster. The labels are implicit, + meaning the zeroth/first entry in the array belongs to the first cluster, + the second entry to the second cluster and so on and so forth. + The first cluster has the value of identifier_offset as its identifier. + The second cluster has identifier_offset + 1, and so on and so forth. + + + + + + + diff --git a/base_classes/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml similarity index 73% rename from base_classes/NXcollectioncolumn.nxdl.xml rename to contributed_definitions/NXcollectioncolumn.nxdl.xml index 3f87c37c4..5348d55b5 100644 --- a/base_classes/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Subclass of NXelectronanalyser to describe the electron collection - column of a photoelectron analyser. + Subclass of NXelectronanalyser to describe the electron collection column of a + photoelectron analyser. - Scheme of the electron collection lens, i.e. angular dispersive, - spatial dispersive, momentum dispersive, non-dispersive, etc. + Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum + microscope, etc. @@ -48,7 +48,7 @@ Distance between sample and detector entrance - + Labelling of the lens setting in use. @@ -62,20 +62,6 @@ - - - Acceptance angle of the collection column. - - This concept is related to term `7.4`_ of the ISO 18115-1:2023 standard. - - .. _7.4: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.4 - - - - - Acceptance length or area of the collection column. - - The magnification of the electron lens assembly. @@ -99,19 +85,6 @@ the reference coordinate system. - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - The size and position of an aperture inserted in the column, e.g. field aperture @@ -128,5 +101,4 @@ Individual lenses in the collection column section - diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml new file mode 100644 index 000000000..c2276f3a9 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system_set.nxdl.xml @@ -0,0 +1,137 @@ + + + + + + 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/NXcs_computer.nxdl.xml b/contributed_definitions/NXcs_computer.nxdl.xml new file mode 100644 index 000000000..b6cd467a2 --- /dev/null +++ b/contributed_definitions/NXcs_computer.nxdl.xml @@ -0,0 +1,80 @@ + + + + + + + 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.nxdl.xml b/contributed_definitions/NXcs_cpu.nxdl.xml new file mode 100644 index 000000000..b27b87481 --- /dev/null +++ b/contributed_definitions/NXcs_cpu.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 (CPU) of a computer. + + + + Given name of the CPU. Users should be as specific as possible. + + + + diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml similarity index 53% rename from base_classes/NXcs_filter_boolean_mask.nxdl.xml rename to contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index c8b1f0457..fe1707aa1 100644 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -1,4 +1,4 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -43,41 +43,33 @@ - Base class for packing and unpacking booleans. + Computer science base class for packing and unpacking booleans. - This base class bookkeeps metadata to inform software about necessary modulo - operations to decode e.g. set membership of objects in sets which are encoded - as a packed array of boolean values. + One use case is processing of object sets (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. - One use case is processing of object sets (e.g. point cloud data). If e.g. a - spatial filter has been applied to a set of points we may wish to store - document efficiently which points were analyzed. Array of boolean values - is one option to achieve this. A value is true if the point is included. - The resulting boolean array will be filled with true and false values - in a manner that is often arbitrary and in general case-dependent. + 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. - Especially when the number of points is large, for instance several thousands - or more, some situations can be more efficiently stored if one does not store - the boolean array but just lists the identifiers of the points taken. - - For example, if within a set of 1000 points only one point is included, it would - take (naively) 4000 bits to store the array but only 32 bits to store e.g. the - ID of the single point that is taken. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore, boolean masks are useful in that - they store compact representation of set memberships. - - This base class can deal with the situation when the number of objects - is not an integer multiple of the bit depth used for storing the states. + 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. - - - Possibility to refer to which set this mask applies. - - If depends_on is not provided, it is assumed that the mask - applies to its direct parent. - - Number of objects represented by the mask. @@ -91,21 +83,19 @@ - The content of the mask. If padding is used, - padding bits have to be set to 0. + 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. Resolving of identifier follows - the conventions made for depends_on, so consult also the description - of th content to which depends_on refers. + identifier and so on and so forth. diff --git a/contributed_definitions/NXcs_gpu.nxdl.xml b/contributed_definitions/NXcs_gpu.nxdl.xml new file mode 100644 index 000000000..3392e41d3 --- /dev/null +++ b/contributed_definitions/NXcs_gpu.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/base_classes/NXidentifier.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml similarity index 55% rename from base_classes/NXidentifier.nxdl.xml rename to contributed_definitions/NXcs_io_obj.nxdl.xml index ce05800f9..eb1e7e19c 100644 --- a/base_classes/NXidentifier.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -1,10 +1,10 @@ - + - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - An identifier for a (persistent) resource, e.g., a DOI or orcid. + Computer science description of a storage object in an input/output system. - + - The service by which the resource can be resolved. - - Examples: doi, urn, hdl, purl, orcid, iso, url + Qualifier for the type of storage medium used. + + + + + - + + - The unique code, IRI or hash to resolve this reference. - Typically, this is stated by the service which is considered a complete - identifier, e.g., for a DOI it's something of the form `10.1107/S1600576714027575` - or `https://doi.org/10.1107/S1600576714027575`, which are both resolvable. + Total amount of data which the medium can hold. - + + - True if the identifier is persistent (i.e., unique and available indefinitely), - False otherwise. + Given name to the I/O unit. + diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml similarity index 75% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXcs_io_sys.nxdl.xml index 94857e74c..5608c9f88 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXcs_io_sys.nxdl.xml @@ -1,10 +1,10 @@ - + - - - Base class to describe a region-of-interest analyzed. - - + + - Details about processing steps. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of system of a computer. + + diff --git a/base_classes/NXem_method.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml similarity index 57% rename from base_classes/NXem_method.nxdl.xml rename to contributed_definitions/NXcs_mm_sys.nxdl.xml index e5e0dc074..d9c6779fd 100644 --- a/base_classes/NXem_method.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -1,4 +1,4 @@ - + - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - 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_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + Computer science description of a main memory system of a computer. - + - Details about processing steps. + How much physical memory does the system provide. - - - - - + + diff --git a/base_classes/NXcs_prng.nxdl.xml b/contributed_definitions/NXcs_prng.nxdl.xml similarity index 62% rename from base_classes/NXcs_prng.nxdl.xml rename to contributed_definitions/NXcs_prng.nxdl.xml index 911faf63c..16d192c4c 100644 --- a/base_classes/NXcs_prng.nxdl.xml +++ b/contributed_definitions/NXcs_prng.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -30,25 +30,21 @@ Computer science description of pseudo-random number generator. - The purpose of this base class is to identify if exactly the same sequence + 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). - + - Physical approach or algorithm whereby random numbers are generated. - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device whose the state is unpredictable - (physically). Some use a strategy of mangling information from the system - clock. Also in this case the sequence is not reproducible without having - additional pieces of information. - - In most cases though so-called pseudo-random number generator (PRNG) - algorithms are used. These yield a deterministic sequence of practically - randomly appearing numbers. These algorithms differ in their quality in - how close the resulting sequences are random, i.e. sequentially - uncorrelated. Nowadays one of the most commonly used algorithm is the - MersenneTwister (mt19937). + 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). @@ -57,24 +53,30 @@ - + 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 controlling the specific sequence generated. + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. - + + - Number of initial draws from the PRNG after its initialized with the seed. - These initial draws are typically discarded in an effort to equilibrate the - sequence. If no warmup was performed or if warmup procedures are unclear, + 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/contributed_definitions/NXcs_profiling.nxdl.xml similarity index 72% rename from base_classes/NXcs_profiling.nxdl.xml rename to contributed_definitions/NXcs_profiling.nxdl.xml index d37224f9c..97105a1b2 100644 --- a/base_classes/NXcs_profiling.nxdl.xml +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description for performance and profiling data of an application. + 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 @@ -38,29 +38,28 @@ * Software configuration and capabilities * Dynamic effects of the system in operation and the system working together with eventually multiple computers, especially when these have to exchange - information across a network and these are used usually by multiple users. + 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) took. - A frequent idea is here to answer practical questions like how critical is the - effect on the workflow of the scientists, i.e. is the analysis possible in - a few seconds or would it take days if I were to run this analysis on a - comparable machine? - For this more qualitative performance monitoring, mainly the order of - magnitude is relevant, as well as how this was achieved using parallelization - (i.e. reporting the number of CPU and GPU resources used, the number of - processes and threads configured, and providing basic details about the computer). + 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 + state of call stacks, in short eventually the entire app execution history and hardware state history. Such analyses are mainly used for performance - optimization, i.e. by software and hardware developers as well as for - tracking bugs. Specialized software exists which documents such performance - data in specifically-formatted event log files or databases. + 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 for now. - Instead, the intention of the base class is to serve scientists at the + 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 @@ -71,12 +70,12 @@ the metadata in this base class. - + Path to the directory from which the tool was called. - + Command line call with arguments if applicable. @@ -98,15 +97,15 @@ Wall-clock time how long the app execution took. This may be in principle end_time minus start_time; however usage of eventually more precise timers may warrant to use a finer temporal discretization, - and thus demands a more precise record of the wall-clock time. + 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 e.g. for apps which use e.g. MPI - (Message Passing Interface) parallelization is to communicate - how many processes were used. + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, 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 @@ -115,14 +114,14 @@ used though. - + - Qualifier how many nominal threads were used at runtime. - Specifically here the maximum number of threads used for the + 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. @@ -130,7 +129,8 @@ +complicated models should be captured. +how can you have an empty list?--> A collection with one or more computing nodes each with own resources. diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml similarity index 82% rename from base_classes/NXcs_profiling_event.nxdl.xml rename to contributed_definitions/NXcs_profiling_event.nxdl.xml index 9da91f9c0..195dee88c 100644 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -47,34 +47,31 @@ included when the event tracking ended. - + Free-text description what was monitored/executed during the event. - Wall-clock time how long the event took. - - This may be in principle end_time minus start_time; however usage of - eventually more precise timers may warrant to use a finer temporal - discretization, and thus demand for a more precise record of the - wall-clock time. - + 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. diff --git a/contributed_definitions/NXdac.nxdl.xml b/contributed_definitions/NXdac.nxdl.xml new file mode 100644 index 000000000..44583e251 --- /dev/null +++ b/contributed_definitions/NXdac.nxdl.xml @@ -0,0 +1,38 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Digital-to-analog converter component/integrated circuit. + + + + TBD. + + + diff --git a/contributed_definitions/NXdata_mpes.nxdl.xml b/contributed_definitions/NXdata_mpes.nxdl.xml deleted file mode 100644 index 8fe879134..000000000 --- a/contributed_definitions/NXdata_mpes.nxdl.xml +++ /dev/null @@ -1,134 +0,0 @@ - - - - - - :ref:`NXdata_mpes` describes the plottable data and related dimension scales in photoemission - experiments. - - It extends the NXdata class and provides a glossary of explicitly named axis names - which are typical for photoemission data. - - - - Calibrated energy axis. - - Could be linked from the respective '@reference' field. - - - - The energy can be either stored as kinetic or as binding energy. - - - - - Calibrated kinetic energy axis. - - This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. - - .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - - - - - Calibrated binding energy axis. - - This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. - - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - - - The energy can be dispersed according to different strategies. ``@reference`` points to - the path of a field defining the calibrated axis which the ``energy`` axis refers. - - For example: - @reference: 'entry/process/energy_calibration/calibrated_axis' - @reference: 'entry/process/energy_referencing/calibrated_axis' - - - - - - One calibrated k-space coordinate. It is envisioned that the axes are named kx, ky, and kz, - in accordance with the calibrations defined in NXprocess_mpes. - - Typically, the vectors in momentum space are defined such that kx and ky comprise the parallel component, - while kz is taken as the perpendicular component. - - It is also possible to define k_parallel and k_perp for the parallel and perpendicular momenta, respectively. - Units are 1/Angström. - - - - - One calibrated angular coordinate. It is envisioned that the axes are name angular0, angular1, etc., - in accordance with the calibrations defined in NXprocess_mpes. - - The angular axes should be named in order of decreasing speed, i.e., angular0 should be - the fastest scan axis and angular1 should be the slow-axis angular coordinate. However, - angular0 may also be second slow axis if the measurement is angularly integrated and angular1 - could also be the second fast axis in the case of simultaneous dispersion in two angular - dimensions. - - - - - One calibrated spatial coordinate. It is envisioned that the axes are name spatial0, spatial1, etc., - in accordance with the calibrations defined in NXprocess_mpes. - - The spatial axes should be named in order of decreasing speed, i.e., spatial0 should be - the fastest scan axis and spatial1 should be the slow-axis spatial coordinate. However, - spatial0 may also be second slow axis if the measurement is spatially integrated and spatial1 - could also be the second fast axis in the case of simultaneous dispersion in two spatial - dimensions. - - - - - Calibrated delay time. - - - - - Linear polarization angle of the incoming or outgoing beam. - - In an application definition, this could be a link to - /entry/instrument/beam/incident_polarization_angle or - /entry/instrument/beam/final_polarization_angle if they exist. - - - - - Ellipticity of the incoming or outgoing beam. - - Can be any of linear polarization angle (degrees), ellipticity (arb. units). - In an application definition, this could be a link to - /entry/instrument/beam/incident_ellipticity or - /entry/instrument/beam/final_ellipticity if they exist. - - - diff --git a/contributed_definitions/NXdata_mpes_detector.nxdl.xml b/contributed_definitions/NXdata_mpes_detector.nxdl.xml deleted file mode 100644 index 3faebab2f..000000000 --- a/contributed_definitions/NXdata_mpes_detector.nxdl.xml +++ /dev/null @@ -1,147 +0,0 @@ - - - - - - :ref:`NXdata_mpes_detector` describes the plottable data and related - dimension scales for raw detector data in photoemission experiments. - - It extends the NXdata class and provides a glossary of explicitly named axis names - which are typical for raw photoemission data. - - - - Raw data before calibration. - - - - - Detector pixel in x direction. - - - - - Detector pixel in y direction. - - - - - (Un)calibrated energy axis. - - - - The energy can be either stored as kinetic or as binding energy. - - - - - (Un)calibrated kinetic energy axis. - - This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. - - .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - - - - - (Un)calibrated binding energy axis. - - This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. - - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - - - - One (un)calibrated k-space coordinate. It is envisioned that the axes are named kx, ky, and kz. - - Typically, the vectors in momentum space are defined such that kx and ky comprise the parallel component, - while kz is taken as the perpendicular component. - - It is also possible to define k_parallel and k_perp for the parallel and perpendicular momenta, respectively. - Units are 1/Angström. - - - - - One (un)calibrated angular coordinate. It is envisioned that the axes are name angular0, angular1, etc. - - The angular axes should be named in order of decreasing speed, i.e., angular0 should be - the fastest scan axis and angular1 should be the slow-axis angular coordinate. However, - angular0 may also be second slow axis if the measurement is angularly integrated and angular1 - could also be the second fast axis in the case of simultaneous dispersion in two angular - dimensions. - - - - - One (un)calibrated spatial coordinate. It is envisioned that the axes are name spatial0, spatial1, etc. - - The spatial axes should be named in order of decreasing speed, i.e., spatial0 should be - the fastest scan axis and spatial1 should be the slow-axis spatial coordinate. However, - spatial0 may also be second slow axis if the measurement is spatially integrated and spatial1 - could also be the second fast axis in the case of simultaneous dispersion in two spatial - dimensions. - - - - - - Total time of flight. - - - - - Time-of-flight values, analog-to-digital converted. - - - - - (Un)calibrated delay time. - - - - - Linear polarization angle of the incoming or outgoing beam. - - - - - Ellipticity of the incoming or outgoing beam. - - - - - Describes an axis which is coming from outside the detectors scope. - - Think of a detector just being triggered for readout by the rest of the experimental - setup - it would just know that it collected N images, which would flatten the external - parameters to one axis, too. - This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument - and write it to the top-level NXdata_mpes. - - - diff --git a/base_classes/NXdeflector.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml similarity index 77% rename from base_classes/NXdeflector.nxdl.xml rename to contributed_definitions/NXdeflector.nxdl.xml index 10e699c88..abdea5bbb 100644 --- a/base_classes/NXdeflector.nxdl.xml +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -1,10 +1,10 @@ - + - + Deflectors as they are used e.g. in an electron analyser. - + - Qualitative type of deflector with respect to the number of pole pieces. + Qualitative type of deflector with respect to the number of pole pieces @@ -36,54 +36,52 @@ - + Colloquial or short name for the deflector. For manufacturer names and identifiers use respective manufacturer fields. - - + - Ideally an identifier, persistent link, or free text which gives - further details about the deflector. + Name of the manufacturer who built/constructed the deflector. - + - Excitation voltage of the deflector. For dipoles it is a single number. - For higher order multipoles, it is an array. + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. - + - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. - + - Spatial offset of the deflector in x direction (perpendicular to - ```offset_y```). + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - + - Spatial offset of the deflector in y direction (perpendicular to - ```offset_x```). + 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 - :ref:`NXtransformations` base class are used. In principle, the McStas coordinate + 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/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 8fd3685a1..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. @@ -41,30 +41,30 @@ Number of atoms in the whitelist. - + Number of isotopes in the whitelist. - 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. - + - Details about the grid on which the delocalization is applied. + Reference or link to the grid on which the delocalization is applied. - - + + + + Reference or link to the points which are delocalized on the grid. + + - + - The weighting model specifies how mark data are mapped to a weight per - point/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 ion species + * atomic_decomposition, points get as much weight as they have atoms + of a type in element_whitelist, + * isotope_decomposition, points get as much weight as they have + isotopes of a type in isotope_whitelist. + + This description shows an example that could be reinterpreted for + similar such data processing steps in other fields of science. - - - As an example from the research field of atom probe points/objects are (molecular) ions. - Different methods are used for weighting ions: - - * default, points get all the same weight 1., which for atom probe is equivalent - to (molecular) iontype-based delocalization. - * element, points get as much weight as they have atoms representing a nuclide - with a proton number that is matching to a respective entry in whitelist. - In atom probe jargon, this means atomic_decomposition. - * isotope, points get as much weight as they have atoms representing a nuclides - from a respective entry in whitelist. - In atom probe jargon, this means isotope_decomposition. - - - - - - - - - - - - - - - - A list of nuclides based on which to evaluate the weight. Nuclides need to exist in the nuclide table. - Values are nuclide (isotope) hash values using the following hashing rule :math:`H = Z + N \cdot 256` - with :math:`Z` the number of protons and :math:`N` the number of neutrons of the nuclide. - For elements set :math:`N` to zero. - - - - - - - - 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. - - - - - - - - - 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, - according to the details of the weighting_method. - - - - - - + + + + + + + + + + A list of elements (via proton number) to consider for the atomic_decomposition + weighting model. Elements must exist in the periodic table of elements. + + + + + + + + A list of isotopes to consider for the isotope_decomposition weighting model. + Isotopes must exist in the nuclid table. Entries in the fastest changing + dimension should be the pair of proton (first entry) and neutron number + (second entry). + + + + + + + + + Attribute data for each member of the point cloud. For APM these are the + ion species labels generated via ranging. The number of mark data per + point is 1 in the case for atom probe. + + + + + + + + + Weighting factor with which the integrated intensity per grid cell is + multiplied specifically for each point. For APM the weight are positive + integer values, specifically the multiplicity of the ion, + according to the details of the weighting_model. + + diff --git a/contributed_definitions/NXdispersive_material.nxdl.xml b/contributed_definitions/NXdispersive_material.nxdl.xml index bc70d81a8..e4e4118b6 100644 --- a/contributed_definitions/NXdispersive_material.nxdl.xml +++ b/contributed_definitions/NXdispersive_material.nxdl.xml @@ -46,6 +46,15 @@ + + Name of the program used for creating this dispersion + + + Version of the program used + + + Date and time of creating this dispersion. + @@ -222,4 +231,4 @@ - \ No newline at end of file + diff --git a/base_classes/NXdistortion.nxdl.xml b/contributed_definitions/NXdistortion.nxdl.xml similarity index 100% rename from base_classes/NXdistortion.nxdl.xml rename to contributed_definitions/NXdistortion.nxdl.xml diff --git a/base_classes/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml similarity index 59% rename from base_classes/NXebeam_column.nxdl.xml rename to contributed_definitions/NXebeam_column.nxdl.xml index d4fc0f153..03b54b779 100644 --- a/base_classes/NXebeam_column.nxdl.xml +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -1,10 +1,10 @@ - + - - + + - Base class for a set of components providing a controllable electron beam. + Container for components to form a controlled beam in electron microscopy. - - - Typically tech-partner, microscope-, and control software-specific - name of the specific operation mode how the ebeam_column and its - components are controlled to achieve a specific illumination condition. - - In most cases users do not know, have to care, or are able to disentangle the - details of the spatiotemporal dynamics of the components of the microscope. - Instead, they rely on the assumption that the microscope and control software - work as expected. Selecting then a specific operation_mode assures some level - of reproducibility in the illumination conditions. - - - 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. @@ -67,22 +52,27 @@ part "an electron gun" reusable in other context--> - + 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. @@ -92,26 +82,28 @@ part "an electron gun" reusable in other context--> relevant from maintenance point of view--> - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. + 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 characterization results for the position, shape, + Individual ocharacterization results for the position, shape, and characteristics of the electron beam. - :ref:`NXtransformations` should be used to specify the location + 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/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml new file mode 100644 index 000000000..b082b310c --- /dev/null +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -0,0 +1,357 @@ + + + + + + + + + + + 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/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_calorimetry.nxdl.xml b/contributed_definitions/NXem_calorimetry.nxdl.xml deleted file mode 100644 index 632722293..000000000 --- a/contributed_definitions/NXem_calorimetry.nxdl.xml +++ /dev/null @@ -1,299 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - - Number of pattern - - - - - Number of azimuthal integration bins - - - - - Number of coordinates along i axis. - - - - - Number of coordinates along j axis. - - - - - Application definition for minimal example in-situ calorimetry. - - What is the technique about. - - General context. - - Literature references. - - - - - - - - - - - - - - - - - - - - - - - - - - Reference to the resource which stores acquired pattern from the experiment. - - Can refer to the original EMD or MRC files or the parsed NXem in RDM e.g. NOMAD OASIS. - - - - - - - - - Reference to the resource which stores actuator log file from the experiment. - - - - - - - - - Assumptions and computations whereby timestamp data from the - detector used for collecting diffraction pattern and the actuator - (heating chip) were synchronized. - - - - - - - - - - Timestamp when pattern acquisition started. - - - - - - - - Timestamp when pattern acquisition ended. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Acquired diffraction pattern azimuthally integrated as a function of time. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Time since start of the in-situ experiment - - - - - - - - - - - - - - - - - - - - - - Azimuthally integrated diffraction intensities corrected for background as a - function of time. - - - - - - - - - - - - - - - - - - - - - - - - - - - - Time since start of the in-situ experiment - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml new file mode 100644 index 000000000..aa3dd46be --- /dev/null +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -0,0 +1,1926 @@ + + + + + + + + + + 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_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/base_classes/NXunit_cell.nxdl.xml b/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml similarity index 54% rename from base_classes/NXunit_cell.nxdl.xml rename to contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml index b20c22cbc..5b0b1ff49 100644 --- a/base_classes/NXunit_cell.nxdl.xml +++ b/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml @@ -1,4 +1,4 @@ - + - + + + + Number of reflectors (Miller crystallographic plane triplets). + + Number of atom positions. @@ -30,123 +35,65 @@ - Description of a unit cell, i.e., the crystal structure of a single - thermodynamic phase. + Crystal structure phase models used for indexing Kikuchi pattern. + + This base class contains key metadata relevant to every physical + kinematic or dynamic diffraction model to be used for simulating + Kikuchi diffraction pattern. + The actual indexing of Kikuchi pattern however maybe use different + algorithms which build on these simulation results but evaluate different + workflows of comparing simulated and measured Kikuchi pattern to make + suggestions which orientation is the most likely (if any) for each + scan point investigated. + + Traditionally Hough transform based indexing has been the most frequently + used algorithm. More and more dictionary based alternatives are used. + Either way both algorithm need a crystal structure model. + - Identifier of an entry resolvable via crystallographic_database - which was used for creating this structure model. + Identifier of an entry from crystallographic_database which was used + for creating this structure model. Name of the crystallographic database to resolve - crystallographic_database_identifier e.g. COD, ICSD, or others. - - - - - A lattice system is a group of lattices with the same set of lattice point groups. - For further information, see https://en.wikipedia.org/wiki/Crystal_system. - - - - - - - - - - - - - - Crystallographic space group. - A space group is the symmetry group of a repeating pattern in space. - For further information, see International Table for Crystallography (https://it.iucr.org/). - - - - - Crystallographic point group. - A crystallographic point group is a set of symmetry operations, corresponding to one of the point groups in three dimensions, - such that each operation (perhaps followed by a translation) would leave the structure of a crystal unchanged. - This field should use Schoenflies notation (see Schoenflies, A., Krystallsysteme und Krystallstructur, 1891). - For further information, see https://dictionary.iucr.org/Point_group. - - - - - Laue group (also called Laue class). - The Laue classes are eleven geometric crystal classes containing centrosymmetric crystallographic types of point groups and their subgroups. - When absorption is negligible and Friedel's law applies, it is impossible to distinguish by diffraction between a centrosymmetric point group - and one of its non-centrosymmetric subgroups; only point groups belonging to different Laue classes can then be distinguished. - For further information, see https://dictionary.iucr.org/Laue_class. + crystallographic_database_identifier e.g. COD or others. - - - Crystallography unit cell parameters a, b, and c - - - - - - - - Crystallography unit cell vector a - - - - - - - For definining which coordinate system the unit cell vector a is defined in. - - - - + - Crystallography unit cell vector b + Crystallography unit cell parameters a, b, and c. - - - For definining which coordinate system the unit cell vector b is defined in. - - - + + - Crystallography unit cell vector c + Crystallography unit cell parameters alpha, beta, and gamma. - - - For definining which coordinate system the unit cell vector c is defined in. - - - + - Crystallography unit cell angles alpha, beta, and gamma + Volume of the unit cell - - - - + - Volume of the unit cell + Crystallographic space group - + True if space group is considered a centrosymmetric one. @@ -163,16 +110,43 @@ False if space group is consider a non-chiral one. + + + Laue group + + + + + + Point group using International Notation. + + + + + + Crystal system + + + + + + + + + + + - Identifier for the phase. - The value 0 is reserved for the unknown phase which represents the null-model - that no phase model was sufficiently significantly confirmed. + Numeric identifier for each phase. + The value 0 is reserved for the unknown phase essentially representing the + null-model that no phase model was sufficiently significantly confirmed. + Consequently, the value 0 must not be used as a phase_identifier. - Trivial name of the phase/alias. + Name of the phase/alias. @@ -185,9 +159,9 @@ - The hash value :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` + 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. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. + 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>`_ @@ -202,13 +176,9 @@ - - - Reference to an instance of NXcoordinate_system whereby the positions can be - resolved. - - + Relative occupancy of the atom position. @@ -217,9 +187,38 @@ - + + + How many reflectors are distinguished. Value has to be n_hkl. + + + + + + Miller indices :math:`(hkl)`. + + + + + + + - For definining which coordinate system the unit cell parameters are defined in. + D-spacing. + + + + + + + Relative intensity of the signal for the plane. + + + + + diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml new file mode 100644 index 000000000..320788851 --- /dev/null +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -0,0 +1,90 @@ + + + + + + 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/NXapm_sim.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 71% rename from base_classes/NXapm_sim.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 90ac529f2..7ec26670c 100644 --- a/base_classes/NXapm_sim.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - - + - Base class for simulating ion extraction from matter via laser and/or voltage - pulsing. + 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/NXfit_parameter.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml similarity index 56% rename from base_classes/NXfit_parameter.nxdl.xml rename to contributed_definitions/NXfabrication.nxdl.xml index f8762232f..1f940f079 100644 --- a/base_classes/NXfit_parameter.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -1,10 +1,10 @@ - + - + - A parameter for a fit function. - This would typically be a variable that - is optimized in a fit. + Details about a component as defined by its manufacturer. - - - The name of the parameter. - - - + - A description of what this parameter represents. + Company name of the manufacturer. - + - The value of the parameter. After fitting, this would store the - optimized value. + Version or model of the component named by the manufacturer. - + - The minimal value of the parameter, to be used as a constraint during fitting. + Ideally, (globally) unique persistent identifier, i.e. + a serial number or hash identifier of the component. - + - The maximal value of the parameter, to be used as a constraint during fitting. + 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 99adeb4d8..69440ae0c 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -1,4 +1,4 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,19 +33,9 @@ - A set of (eventually directed) edges which connect nodes of a graph. - - Use as a direct child of an instance of :ref:`NXgraph_root`. - Alternatively, use depends_on to specify which instance - of :ref:`NXgraph_root` is defined by this instance. + A set of (eventually directed) edges which connect nodes/vertices of a graph. - - - Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_edge_set` - refers to. - - - + Total number of edges, counting eventual bidirectional edges only once. @@ -53,13 +43,14 @@ Integer which specifies the first index to be used for distinguishing - edges. Identifiers are defined either implicitly or explicitly. + 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. - For implicit indexing the identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - For explicit indexing use the field identifier. For implicit indexing, - consult :ref:`NXcg_primitive_set` to get guidance how to set identifier_offset. + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. @@ -70,7 +61,7 @@ - + Specifier whether each edge is non-directional, one-directional, or bidirectional. Use the smallest available binary representation @@ -86,33 +77,34 @@ - Pairs of node/vertex identifier. Each pair represents the connection - between two nodes. The order in the pair encodes eventual directionality. + Pairs of node/vertex identifier. Each pair represents the connection + between two nodes. - In the case that an edge is non- or bi-directional, storing - node identifier in ascending order is preferred. + In the case that the edge is non- or bi-directional + node identifier should be stored in ascending order is preferred. - In the case that an edge is one-directional, node identifier should be - stored such that the identifier of the source node is the first entry - and the identifier of the target is the second entry in the pair. + In the case of one-directional, for each pair the identifier of the source + node is the first entry in the pair. The identifier of the target is the + second entry in the pair, i.e. the pair encodes the information as + if one traverses the edge from the source node walking to the target node. - + A human-readable qualifier which type or e.g. class instance the edge is an instance of. - + - + - A human-readable label/caption/tag of each edge. + A human-readable label/caption/tag for the edge. diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 744f8ae9b..9b98765d2 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -1,4 +1,4 @@ - + - + + The symbols used in the schema to specify e.g. dimensions of arrays. - + - The cardinality of the set, i.e. the number of nodes of the graph. + The dimensionality of the graph. Eventually use one for categorical. - + - The dimensionality of the graph. Eventually use one for categorical. + The cardinality of the set, i.e. the number of nodes/vertices of the graph. - A set of nodes representing members of a graph. - - Use as a direct child of an instance of :ref:`NXgraph_root`. - Alternatively, use depends_on to specify which instance - of NXgraph_root is defined by this instance. + A set of nodes/vertices in space representing members of a graph. - - - Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_node_set` - refers to. - - - - - About which space does the graph make statements. - - - - - - - - - Dimensionality of the space about which the graph makes statements. - Use only when value of the field space is euclidean. - - - - - - - - - - Number of nodes of the graph. - - + + Integer which specifies the first index to be used for distinguishing - nodes. Identifiers are defined either implicitly or explicitly. - - For implicit indexing the identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. + nodes. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. - For explicit indexing use the field identifier. For implicit indexing, - consult :ref:`NXcg_primitive_set` to get guidance how to set identifier_offset. + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. @@ -95,24 +64,26 @@ - + A human-readable qualifier which type or e.g. class instance the - node is an instance of. An example: a NeXus application definition is a - graph, more specifically a hierarchical directed labelled property graph. - Instances which are groups like :ref:`NXgraph_node_set` could have an is_a - qualifier reading :ref:`NXgraph_node_set`. + node is an instance of. As e.g. a NeXus application definition is a + graph, more specifically a hierarchical directed labelled property graph, + instances which are groups like NXgraph_node_set could have an is_a + qualifier reading NXgraph_node_set. - + - A human-readable label/caption/tag of each node. + A human-readable label/caption/tag of the graph. + diff --git a/contributed_definitions/NXgraph_root.nxdl.xml b/contributed_definitions/NXgraph_root.nxdl.xml index 6fc5f054c..0e41c38d4 100644 --- a/contributed_definitions/NXgraph_root.nxdl.xml +++ b/contributed_definitions/NXgraph_root.nxdl.xml @@ -1,4 +1,4 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -32,4 +32,5 @@ + diff --git a/base_classes/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml similarity index 57% rename from base_classes/NXibeam_column.nxdl.xml rename to contributed_definitions/NXibeam_column.nxdl.xml index 9600764bb..0377b93f4 100644 --- a/base_classes/NXibeam_column.nxdl.xml +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -1,4 +1,4 @@ - + - + + - Base class for a set of components equipping an instrument with FIB capabilities. + Container for components of a focused-ion-beam (FIB) system. - Focused-ion-beam (FIB) capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation technique whereby - portions of the sample are illuminated with a focused ion beam with controlled - intensity. The beam is intense enough and with sufficient ion momentum to - remove material in a controlled manner. + 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 the definition of an own base class to group these - components and distinguish them from the lenses and components for creating - and shaping the electron beam. + 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>`_ + * `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. @@ -69,7 +71,7 @@ - + Ideally, a (globally) unique persistent identifier, link, or text to a resource which gives further details. @@ -78,56 +80,65 @@ Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, + Examples are gallium, helium, neon, argon, krypton, or xenon, O2+. - - - Average/nominal flux - - - + + Average/nominal brightness - + Charge current - + - Ion acceleration voltage upon source exit and - entering the vacuum flight path. + Ion acceleration voltage upon source exit and entering the vacuum flight path. - + + - To be defined more specifically. Community suggestions are welcome. + 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. - :ref:`NXtransformations` should be used to specify the location or position + 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_set.nxdl.xml b/contributed_definitions/NXimage_set.nxdl.xml new file mode 100644 index 000000000..a482480c8 --- /dev/null +++ b/contributed_definitions/NXimage_set.nxdl.xml @@ -0,0 +1,128 @@ + + + + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXimage_set_em_adf.nxdl.xml b/contributed_definitions/NXimage_set_em_adf.nxdl.xml new file mode 100644 index 000000000..21616ca47 --- /dev/null +++ b/contributed_definitions/NXimage_set_em_adf.nxdl.xml @@ -0,0 +1,156 @@ + + + + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of annular dark field images. + + Virtually the most important case is that spectra are collected in + a scanning microscope (SEM or STEM) for a collection of points. + The majority of cases use simple d-dimensional regular scan pattern, + such as single point, line profiles, or (rectangular) surface mappings. + The latter pattern is the most frequently used. + + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. + + + + Details how (HA)ADF images were processed from the detector readings. + + + + Typically the name of the input, (vendor) file from which all + the NXdata instances in this NXimage_set_em_adf were loaded during + parsing to represent them in e.g. databases. + + + + An at least as strong as SHA256 hashvalue of the dataset/file + which represents the source digitally to support provenance tracking. + + + + + + Commercial or otherwise given name to the program which was used + to process detector data into the adf image(s). + + + + Program version plus build number, commit hash, or description + of an ever persistent resource where the source code of the program + and build instructions can be found so that the program + can be configured in such a manner that the result file + is ideally recreatable yielding the same results. + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + Annular dark field image stack. + + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image ID. + + + + + + Pixel center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml b/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml new file mode 100644 index 000000000..776b53930 --- /dev/null +++ b/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml @@ -0,0 +1,205 @@ + + + + + + + + Number of scanned points. Scan point may have none, one, or more pattern. + + + + + Number of diffraction pattern. + + + + + Number of pixel per Kikuchi pattern in the slow direction. + + + + + Number of pixel per Kikuchi pattern in the fast direction. + + + + + Measured set of electron backscatter diffraction data, aka Kikuchi pattern. + Kikuchi pattern are the raw data for computational workflows in the field + of orientation (imaging) microscopy. The technique is especially used in + materials science and materials engineering. + + Based on a fuse of the `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ + of the DREAM.3D community and the open H5OINA format of Oxford Instruments + `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ + + EBSD can be used, usually with FIB/SEM microscopes, for three-dimensional + orientation microscopy. So-called serial section analyses. For a detailed + overview of these techniques see e.g. + + * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ + * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ + * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ + + With serial-sectioning this involves however always a sequence of measuring, + milling. In this regard, each serial section (measuring) and milling + is an own NXevent_data_em instance and thus there such a three-dimensional + characterization should be stored as a set of two-dimensional data, + with as many NXevent_data_em instances as sections were measured. + + These measured serial sectioning images need virtually always post-processing + to arrive at the aligned and cleaned image stack before a respective digital + model of the inspected microstructure can be analyzed. The resulting volume + is often termed a so-called (representative) volume element (RVE). + Several software packages are available for performing this post-processing. + For now we do not consider metadata of these post-processing steps + as a part of this base class because the connection between the large variety + of such post-processing steps and the measured electron microscopy data + is usually very small. + + If we envision a (knowledge) graph for EBSD it consists of individual + sub-graphs which convey information about the specimen preparation, + the measurement of the specimen in the electron microscope, + the indexing of the collected Kikuchi pattern stack, + eventual post-processing of the indexed orientation image + via similarity grouping algorithms to yield (grains, texture). + Conceptually these post-processing steps are most frequently + serving the idea to reconstruct quantitatively so-called + microstructural features (grains, phases, interfaces). Materials scientists + use these features according to the multi-scale materials modeling paradigm + to infer material properties. They do so by quantifying correlations between + the spatial arrangement of the features, their individual properties, + and (macroscopic) properties of materials. + + + + + Details how Kikuchi pattern were processed from the detector readings. + Scientists interested in EBSD should inspect the respective NXem_ebsd + application definition which can be used as a partner application definition + to detail substantially more details to this processing. + + + + + Collected Kikuchi pattern as an image stack. As raw and closest to the + first retrievable measured data as possible, i.e. do not use this + container to store already averaged, filtered or whatever post-processed + pattern unless these are generated unmodifiably by the instrument + given the way how the instrument and control software was configured + for your microscope session. + + + + Array which resolves the scan point to which each pattern belongs. + Scan points are evaluated in sequence starting from scan point zero + until scan point n_sc - 1. Evaluating the cumulated of this array + decodes which pattern in intensity belong to which scan point. + In an example we may assume we collected three scan points. For the first + we measure one pattern, for the second we measure three pattern, + for the last we measure no pattern. + The values of scan_point_identifier will be 0, 1, 1, 1, as we have + measured four pattern in total. + + In most cases usually one pattern is averaged by the detector for + some amount of time and then reported as one pattern. Use compressed + arrays allows to store the scan_point_identifier efficiently. + + + + + + + + Signal intensity. For so-called three-dimensional or serial sectioning + EBSD it is necessary to follow a sequence of specimen surface preparation + and data collection. In this case users should collect the data for each + serial sectioning step in an own instance of NXimage_set_em_kikuchi. + All eventual post-processing of these measured data should be documented + via NXebsd, resulting microstructure representations should be stored + as NXms. + + + + + + + + + + Kikuchi pattern intensity + + + + + + + Pattern are enumerated starting from 0 to n_p - 1. + + + + + + + Kikuchi pattern identifier + + + + + + Pixel coordinate along the y direction. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the x direction. + + + + + + + Label for the x axis + + + + + + diff --git a/contributed_definitions/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/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/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index 182fe9810..8c4361d27 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -1,4 +1,4 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,35 +33,24 @@ - Base class for describing isocontouring/phase-fields in Euclidean space. + Computational geometry description of isocontouring/phase-fields in Euclidean space. - Iso-contouring algorithms such as Marching Cubes and others are frequently - used to segment d-dimensional regions at crossings of a threshold value, - the so-called isovalue. + Iso-contouring algorithms such as MarchingCubes and others are frequently + used to segment d-dimensional regions into regions where intensities are + lower or higher than a threshold value, the so-called isovalue. - In Computational Materials Science phase-field methods are frequently used. - Phase-field variables are discretized frequently using regular grids. - - Isocontour algorithms are often used in such context to pinpoint the - locations of microstructural features from this implicit phase-field- - variable-value-based description. + Frequently in computational materials science phase-field methods are + used which generate data on discretized grids. Isocontour algorithms + are often used in such context to pinpoint the locations of microstructural + features from this implicit phase-field-variable-based description. One of the key intentions of this base class is to provide a starting point - for scientists from the phase-field community (condensed-matter physicists, - and materials engineers) to incentivize that also phase-field (and other) - simulation data can take advantage of NeXus base class to improve - interoperability. + for scientists from the phase-field community (condensed matter physicists, + and materials engineers) to incentivize that also phase-field simulation + data could be described with NeXus, provided base classes such as the this one + get further extend according to the liking of the phase-field community. - - - The dimensionality of the space in which the isocontour is embedded. - - - - - - - + The discretized grid on which the iso-contour algorithm operates. diff --git a/contributed_definitions/NXiv_bias.nxdl.xml b/contributed_definitions/NXiv_bias.nxdl.xml deleted file mode 100644 index a23dd8976..000000000 --- a/contributed_definitions/NXiv_bias.nxdl.xml +++ /dev/null @@ -1,192 +0,0 @@ - - - - - - Application definition for bias devices. - - - - Applied a voltage between tip and sample. - - - - - The ratio between the tunneling current at the sample surface and the bias voltage - applied between the sample and the tip. - - - - - Calibration of the Bias output (V/V). - - - - - Allows compensating for an offset in Bias. Hardware parameter offset. - - - - - Sets the amplitude (in physical units of the modulated signal) of the sine - modulation. - - - - - Bias sweeps while measuring arbitrary channels with I(V) curves. - - - - - Select the channels to record. - - - - - When selected, the Bias voltage returns to the initial value (before starting the sweep) at - the end of the spectroscopy measurement (default). When not selected, Bias remains at the - last value of the sweep. This is useful e.g. when combining several sweep segments. Example - for an automated measurement (using Programming Interface): switch off Z-Controller, start - spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, - switch on Z-Controller. - - - - - Select whether to record the Z position during Z averaging time at the end of - the sweep (after Z control time) and store the average value in the header of - the file when saving. Using this option increases the sweep time by Z averaging - time. - - - - - Select whether to set the Lock-In to run during the measurement. When using this - feature, make sure the Lock-In is configured correctly and settling times are - set to twice the Lock-In period at least. This option is ignored when Lock-In is - already running. This option is disabled if the Sweep Mode is MLS and the flag - to configure the Lock-In per segment in the Multiline segment editor is set. - - - - - Time during which the spectroscopy data are acquired and averaged. - - - - - Number of sweeps to measure and average. - - - - - The first bias values of the sweep. - - - - - The last bias values of the sweep. - - - - - Define the sweep number of points, that is, the maximum spectrum resolution eq. - Bias window divide by Num Pixel. - - - - - Duration over which the Z position is recorded and averaged before and after the - sweep (the latter only if Record final Z position is selected in the Advanced - section). After the initial Z averaging time, if Z-Controller to Hold is - selected in the Advanced section, the Z-Controller is set to hold and the tip is - placed at the previously averaged Z position (plus Z offset). - - - - - Select a filter to smooth the displayed data. When saving, if any filter - selected, filtered data are saved to file along with the unfiltered data. - - - - - Filter order of a dynamic filter or width (in number of points) for the gaussian - filter. - - - - - Cutoff frequency for dynamic filters. - - - - - Offset added to the initial averaged position Zaver before starting to sweep. - This parameter is disabled when Z-Controller to Hold is deselected in the - Advanced section. The LED “Alt” next to the Z offset indicates if an alternate - Z-controller setpoint is enabled. - - - - - time to wait after changing the bias to the next level and before starting to - acquire data. - - - - - Time to wait after the sweep has finished and the bias is ramped to the initial - value. - - - - - Time during which the Z-Controller is enabled once a sweep has finished. When - averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this - duration between each sweep. After the last sweep, it will wait the specified - time before continuing a running scan. This ensures each sweep reliably starts - from the same position. This parameter is disabled when Z-Controller to Hold is - deselected in the Advanced section. - - - - - Maximum rate at which the bias changes (before, during and after sweeping). - (V/s) - - - - - Select whether to measure the backward (return) sweep or the forward only. - - - - - Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. - It is selected by default. When deselected, Z-offset and Z-control time - parameters are disabled. - - - diff --git a/contributed_definitions/NXiv_temp.nxdl.xml b/contributed_definitions/NXiv_temp.nxdl.xml index 6d881019a..927c7bba8 100644 --- a/contributed_definitions/NXiv_temp.nxdl.xml +++ b/contributed_definitions/NXiv_temp.nxdl.xml @@ -51,25 +51,6 @@ - - - - Descriptive name or ideally (globally) unique persistent identifier. - - - - - 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. - - - diff --git a/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml b/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml index e9a3ae64d..8bb1e4f93 100644 --- a/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml +++ b/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml @@ -1,4 +1,4 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -54,7 +54,7 @@ - + diff --git a/contributed_definitions/NXlab_sample_mounting.nxdl.xml b/contributed_definitions/NXlab_sample_mounting.nxdl.xml index 4113ea123..9127e4047 100644 --- a/contributed_definitions/NXlab_sample_mounting.nxdl.xml +++ b/contributed_definitions/NXlab_sample_mounting.nxdl.xml @@ -1,4 +1,4 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -53,7 +53,7 @@ - + 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/base_classes/NXlens_opt.nxdl.xml b/contributed_definitions/NXlens_opt.nxdl.xml similarity index 92% rename from base_classes/NXlens_opt.nxdl.xml rename to contributed_definitions/NXlens_opt.nxdl.xml index f413dc19f..753a58e55 100644 --- a/base_classes/NXlens_opt.nxdl.xml +++ b/contributed_definitions/NXlens_opt.nxdl.xml @@ -1,4 +1,4 @@ - + - - + @@ -105,10 +104,8 @@ A draft of a new base class describing an optical lens - + If the lens has a coating describe the material and its properties. Some basic information can be found e.g. [here] @@ -185,14 +182,4 @@ the lens has different coatings on the front and back side. Abbe number (or V-number) of the lens. - - - The numerical aperture of the used incident light optics. - - - - - - - diff --git a/contributed_definitions/NXlockin.nxdl.xml b/contributed_definitions/NXlockin.nxdl.xml deleted file mode 100644 index f72a279d4..000000000 --- a/contributed_definitions/NXlockin.nxdl.xml +++ /dev/null @@ -1,151 +0,0 @@ - - - - - - Base classes definition for lock in devices. - - - - Hardware manufacturers and type of lockin amplifier. - - - - - By mixing the input signal (STS signal) with the modulated signal (such as Bias) - and comparing it with the reference signal, they are enhanced and the effects of - noise interference are reduced, resulting in more accurate measurements. - - - - - if Lock-in -- Bias Divider 1/10 or 1/100, Bias divider = - V(ref)/[V(ref)+V(input)] - - - - - Switch the lock-in moulation on or off. - - - - - A modulation signal (such as bias, current et.al.) is a periodic voltage signal, - usually applied to the surface of a sample, which serves to modify the physical - properties of the sample surface and generate weak AC current signals that can - be detected and analysed by instruments such as lock-in amplifiers. - - - - - - Sets the amplitude (in physical units of the modulated signal) of the sine - modulation. - - - - - Sets the frequency of the sine modulation added to the signal to modulate. - - - - - The input signal (STS signal) will be demodulated, in order to determine the amplitude - and phase at the frequency set in the Frequency field or harmonics, such as current, - bias, et.al. - - - - - - The number of signals which will be demodulated. - - - - - Order and cut-off frequency of the low-pass filter applied on the demodulated - signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) - - - - - Order and cut-off frequency of the high-pass filter applied on the demodulation - signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) - - - - - Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) - value) for D1. The filter is applied to the demodulated signals (X,Y). - - - - - Order and cut-off frequency of the low-pass filter applied on the demodulated - signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on - the demodulated signals, but will require longer settling and measurement times. - - - - - Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) - value) for D1. The filter is applied to the demodulated signals (X,Y). - - - - - Order and cut-off frequency of the high-pass filter applied on the demodulation - signal of D!. This is used mainly to suppress a DC component of the demodulation - signal, which would lead to a component at modulation frequency in the - demodulated signals. - - - - - Switch on/off the Sync filter on the demodulated signals (X,Y) on or off. - (foreach DemodulatorChannels) - - - - - Reference phase for the sine on the demodulated signal with respect to the - modulation signal. (foreach DemodulatorChannels) - - - - - Time during which the data are acquired and averaged. (for the input filter) - - - - - The order of the harmonic oscillation to detect on the demodulated signals. - (with respect to the modulation frequency) - - - - - Ratio of output signal amplitude to input signal amplitue (V/V). (input gain) - - - diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml new file mode 100644 index 000000000..dff2584fc --- /dev/null +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -0,0 +1,100 @@ + + + + + + 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 fde6b345a..482b028d9 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,13 +33,13 @@ - Base class of a filter to select members of a set based on their identifier. + Settings of a filter to select or remove entries based on their value. - + - Definition of the logic what the filter yields: + Meaning of the filter: Whitelist specifies which entries with said value to include. - Entries with all other values will be excluded. + Entries with all other values will be filtered out. Blacklist specifies which entries with said value to exclude. Entries with all other values will be included. @@ -51,9 +51,10 @@ - Array of values to filter according to method. If the match e.g. specifies - [1, 5, 6] and method is set to whitelist, only entries with values matching - 1, 5 or 6 will be processed. All other entries will be excluded. + Array of values to filter according to method. For example if the filter + specifies [1, 5, 6] and method is whitelist, only entries with values + matching 1, 5 or 6 will be processed. All other entries will be filtered + out. diff --git a/contributed_definitions/NXmicrostructure.nxdl.xml b/contributed_definitions/NXmicrostructure.nxdl.xml deleted file mode 100644 index 44d462c04..000000000 --- a/contributed_definitions/NXmicrostructure.nxdl.xml +++ /dev/null @@ -1,776 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - - The number of one-dimensional crystal projections - - - - - The number of one-dimensional interface projections - - - - - - The number of two-dimensional crystal projections - - - - - The number of two-dimensional interface projections - - - - - The number of two-dimensional triple line projections - - - - - The number of two-dimensional line defect projections - - - - - - The number of crystals (grain and sub-grain are exact synonyms for crystal). - - - - - The number of interfaces (grain boundary and phase boundary are subclasses of - interfaces). - - - - - The number of triple junctions (triple line is a exact synonym for triple - junction, triple point is projection of a triple junction). - - - - - The number of quadruple junctions. - - - - - - The dimensionality of the representation that needs to match the value for - configuration/dimensionality - - - - - Base class to describe a microstructure, its structural aspects, associated descriptors, properties. - - Whether one uses a continuum or atomic scale description of materials, these are always a model only of - the true internal structure of a material. Such models are useful as they enable a coarse-graining and - categorizing of properties and representational aspects from which measured or simulated descriptions - can be correlated with properties, i.e. descriptor values. - - Keep in mind that most specimens are thermo-chemo-mechanically processed prior characterization. - Therefore, the characterized microstructure may not have probed the same structure as of the untreated - sample from which the region-of-interests on the specimen were sampled. - - Fields such as time and increment enable a quantification of the spatiotemporal evolution of a materials' - structure by using multiple instances of NXmicrostructure. Both measurements and simulation virtually - always sample this evolution. Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. Often materials are characterized only for - specific states or via sampling coarsely in time relative to the timescale at which the - physical phenomena take place. This is typically a compromise between the research questions at hand and technical surplus practical limitations. - - The term microstructural feature covers here crystals and all sorts of crystal defects within the material. - A key challenge with the description of representations and properties of microstructural features is that - features with different dimensionality exist and combinations of features of different dimensionality are - frequently expected to be documented with intuitive naming conventions using flat property lists. - For these key-value dictionaries often folksonomies are used. These can be based on ad hoc documentation - of such dictionaries in the literature and the metadata section of public data repositories. - - NXmicrostructure is an attempt to standardize these descriptions stronger. - - The descriptive variety is large especially for junctions. Like crystals and interfaces, junctions are features in - three-dimensional Euclidean space even if they are formed maybe only through a monolayer or pearl chain of atoms. - Either way the local atomic and electronic environment is different compared to the situation of an ideal crystal, - which gives typically rise to a plethora of configurations of which some yield useful properties. - - Like crystals and interfaces, junctions are assumed to represent groups of atoms that have specific descriptor values - which are different to other features. Taking an example, a triple junction is practically a three-dimensional defect as its atoms - are arranged in three-dimensional space but the characteristics of that defect can often be reduced to a lower-dimensional - description such as a triple point or a triple line. Therefore, different representations can be used to describe the location, - shape, and structure of the defect. As different types of crystal defects can interact, there is a substantial number of - in principle characterizable and representable objects. Take again a triple line as an example. It is a tubular feature built from three - adjoining interfaces. However, dislocations as line defects can interact with triple lines. Therefore, one can also argue that - along a triple line there can be dislocation-line-triple-line junctions, likewise dislocations form own junctions. - - It is not the aim of this base class to cover all these cases, rather this base class currently provides examples how the - typically most relevant types of features can be represented using a combination of base classes in NeXus. Currently, - these are crystals, interfaces, triple lines, quadruple junctions. - - The description attempt here took inspiration from `E. E. Underwood <https://doi.org/10.1111/j.1365-2818.1972.tb03709.x>`_ - and E. E. Underwood's book on Quantitative Stereology published 1970 to categorize features based on their dimensionality. - - Identifiers can be defined either implicitly or explicitly. Identifiers for implicit indexing are defined - on the interval :math:`[identifier\_offset, identifier\_offset + cardinality - 1]`. - - - - - Discouraged free-text field for leaving comments. - - - - - ISO8601 with offset to local time zone included when a timestamp is required. - - - - - Measured or simulated physical time stamp for this microstructure snapshot. - Not to be confused with wall-clock timing or profiling data. - - - - - Iteration or increment counter. - - - - - Group where to store details about the configuration and parameterization of algorithms - used whereby microstructural features were identified. - - - - Dimensionality of Euclidean space in which the analysis is performed. - - This field can be used e.g. by a research data management system to identify - if the description specifies one-, two-, or three-dimensional microstructural representations. - - - - - - - - - - Algorithm whereby interfaces between crystals were reconstructed. - - * Disorientation clustering groups nearby material points based on their crystallographic disorientation - * Fast multiscale clustering based on `D. Kushnir et al. <https://doi.org/10.1016/j.patcog.2006.04.007>`_ - * Markov chain clustering `F. Niessen et al. <https://doi.org/10.1107/S1600576721011560>`_ - - - - - - - - - - - - Threshold to define at which disorientation angle to assume two crystalline regions have a significant - orientation difference that warrants to assume that there exists an interface between the two regions. - - - - - The program with which the microstructure was reconstructed. - - - - - - - - - - - - - - One- or two-dimensional projections, or three-dimensional representations of crystals. - - An example for a volume bounded by other crystal defects. Crystals can be grains of - different phases, precipitates, dispersoids; there are many terms used specifically in - the materials engineering community. - - Typically, crystals are measured on the surface of a sample via optical or electron microscopy. - Using X-ray diffraction methods crystals can be observed in bulk specimens. - - Crystals are represented by a set of pixel, voxel, or polygons and their polyline boundaries. - In rare cases the volume bounded gets represented using constructive solid geometry approaches. - - - - - Reference to an instance of: - - * :ref:`NXcg_polyline_set` for a one-dimensional representation as only a projection is available (like in linear intercept analysis) - * :ref:`NXcg_polygon_set` for a two-dimensional representation as only a projection is available (like in most experiments) - * :ref:`NXcg_polyhedron_set` or :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions - (like in computer simulations or 3D experiments) - - which represent the geometrical entities of the discretization. - - - - - How many crystals are distinguished. - - Crystals are listed irrespective of the phase to which these are assigned. - - - - - How many phases are distinguished. - - Phases are typically distinguished based on statistical thermodynamics argument and crystal structure. - - - - - First identifier whereby to identify crystals implicitly. - - - - - Identifier whereby to identify each crystal explicitly. - - - - - - - - First identifier whereby to identify phases implicitly. - - - - - Identifier whereby to identify phase for each crystal explicitly. - - - - - - - - - True or false value, one for each crystal, to communicate whether that feature - makes contact with the edge of the ROI. - - - - - - - - Average disorientation angle for each crystal between individual orientations - of that crystal evaluated as a summary statistic for all probed positions vs the - average disorientation of that crystal. - - - - - - - - Length of each crystal - - - - - - - - Area of each crystal. - - - - - - - - Volume of each crystal - - - - - - - - - One- or two-dimensional projections or three-dimensional representation of interfaces - between crystals as topological entities equivalent to dual_junctions. - - An example for a surface defect. Most important are interfaces such as grain and phase boundaries - but factually interfaces also exist between the environment and crystals exposed at the - surface of the specimen or internal surfaces like between crystals, cracks, or pores. - - - - Reference to an instance of: - - * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available (as in linear intercept analyses) - * :ref:`NXcg_polyline_set` or :ref:`NXcg_polygon_set` for a two-dimensional representation as only a projection is available (like in most experiments) - * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks - (like in computer simulations or 3D experiments) - - which represent the geometrical entities of the discretization. - - - - - How many interfaces are distinguished. - - - - - First identifier whereby to identify interfaces implicitly. - - - - - Identifier whereby to identify each interface explicitly. - - - - - - - - - Set of pairs of crystal_identifier for each interface. - - - - - - - - The specific identifiers whereby to resolve ambiguities. - - - - - - Set of pairs of phase_identifier for each interface. - - - - - - - - The specific identifiers whereby to resolve ambiguities. - - - - - - - Set of pairs of triple_junction_identifier for each interface. - - - - - - - - The specific identifiers whereby to resolve ambiguities. - - - - - - - True or false value, one for each crystal, to communicate whether that feature - makes contact with the edge of the ROI. - - - - - - - - Gibbs free surface energy for each interface. - - - - - - - - Non-intrinsic mobility of each interface. - - - - - - - - The length of each interface if only projections are available. - - This is not necessarily the same as the length of the individual - polyline segments whereby the interface is discretized. - - - - - - - - The surface area of all interfaces. - - - - - - - - - Projections or representations of junctions at which three interfaces meet. - - An example for a line defect. Triple junctions are characterized as triple lines or triple points as their projections, - or junctions observed between crystals (at the specimen surface exposed to an environment) - (including wetting phenomena) or inside the specimen (crack, pores). - - - - Reference to an instance of: - - * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available (like in most experiments) - * :ref:`NXcg_polyline_set` for a two-dimensional representation as only a projection is available - * :ref:`NXcg_polygon_set` for a two-dimensional representation in the (seldom) case of sufficient spatial resolution - and the line in the projection plane or cases where triple junction locations are approximated e.g. using a set of triangles - * :ref:`NXcg_polyhedron_set` for a three-dimensional representation via e.g. a representation of Voronoi cells about atoms - * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks - - which represent the geometrical entities of the discretization. - - - - - Number of triple junctions. - - - - - First identifier to identify triple junctions implicitly. - - - - - Identifier to identify each triple junction explicitly. - - - - - - - - - Set of identifier for positions whereby to identify the location of each - junction. - - - - - - - The specific identifiers whereby to resolve ambiguities. - - - - - - Explicit positions. - - - - - - - - - Set of tuples of identifier of crystals connected to the junction for each - triple junction. - - - - - - - - - - Set of tuples of identifier of interfaces connected to the junction for each - triple junction. - - - - - - - - The specific interface identifiers whereby to resolve ambiguities. - - - - - - - Set of tuples of identifier for polyline segments connected to the junction for - each triple junction. - - - - - - - - The specific polyline identifiers whereby to resolve ambiguities. - - - - - - - True or false value, one for each crystal, to communicate whether that feature - makes contact with the edge of the ROI. - - - - - - - - Specific line energy of each triple junction - - - - - - - - Non-intrinsic mobility of each triple junction. - - - - - - - - The length of each triple junction. - - This is not necessarily the same as the length of the individual - polyline segments whereby the junction is discretized. - - - - - - - - The volume of the each triple junction - - - - - - - - - Quadruple junctions as a region where four crystals meet. - - An example for a point defect. - - - - Reference to an instance of: - - * :ref:`NXcg_point_set` - * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks - - - - - Number of quadruple junctions. - - - - - First identifier to identify quadruple junctions implicitly. - - - - - Identifier to identify each quadruple junction explicitly. - - - - - - - - - Set of identifier for positions whereby to identify the location of each - junction. - - - - - - - The specific point identifier whereby to resolve ambiguities. - - - - - - Explicit positions. - - - - - - - - - - Set of tuples of identifier of crystals connected to the junction for each - junction. - - - - - - - - The specific identifier to instances of crystal identifiers whereby to resolve - ambiguities. - - - - - - Set of tuples of identifier of interfaces connected to the junction for each - junction. - - - - - - - - The specific identifier to instances of interface identifiers whereby to resolve - ambiguities. - - - - - - - Set of tuples of identifier for triple junctions connected to the junction for - each quadruple junction. - - - - - - - - The specific identifier to instances of triple junction identifiers whereby to - resolve ambiguities. - - - - - - - Set of tuples of identifier for phases of crystals connected to the junction for - each quadruple junction. - - - - - - - - The specific identifier to instances of phase identifier whereby to resolve - ambiguities. - - - - - - - True or false value, one for each crystal, to communicate whether that feature - makes contact with the edge of the ROI. - - - - - - - - Energy of the quadruple_junction as a defect. - - - - - - - - Non-intrinsic mobility of each quadruple_junction. - - - - - - - diff --git a/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml deleted file mode 100644 index e078938cf..000000000 --- a/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml +++ /dev/null @@ -1,369 +0,0 @@ - - - - - - - Application definition for configuring GraGLeS. - - GraGLeS is a continuum-scale model for shared-memory-parallelized simulations - of the isothermal evolution of 2D and 3D grain boundary networks with a level-set approach. - CPU parallelization is achieved with OpenMP. - - The code has been implemented by C. Mießen in the group of G. Gottstein - at the Institute für Metallkunde und Metallphysik, RWTH Aachen University. - - Details of the model are summarized in `C. Mießen <https://publications.rwth-aachen.de/record/709678>`_. - - - - - - - - - - Simulation ID as an alias to refer to this simulation. - - - - - Discouraged free-text field to add further details to the computation. - - - - - - - - - - - - - - - Programs and libraries representing the computational environment - - - - - - - - - - - - From which file should the microstructure be instantiated. - - - - - - - - - The formulation of mean curvature flow in the GraGLeS model is scale invariant. - Therefore, the discretization has to be scaled to the actual physical length - of the simulation domain (ve, ROI). - For GraGLeS the discretization is always a square or cubic axis-aligned - bounding box with a regular tiling into material points - (either squares or cubes respectively). - - Edge_length is the length of the entire domain along its edge not - the length of the Wigner-Seitz cell about each material point! - - - - - - Configuration when snapshots of the system should be taken. - - Keep in mind that essentially geometry snapshot data store the - polylines and polyhedra of all grains which can take substantial disk - space. - - - - Generate a snapshot of the properties of the grains to follow - the evolution of the microstructure every :math:`n`-th iteration. - Setting zero causes that no property snapshots are taken. - - - - - Generate a snapshot of the geometry of the entire grain boundary network - every :math:`n`-th iteration. Setting zero instructs to store no geometry data. - - - - - - - Configuration when the simulation should be stopped in a controlled manner. - Whichever criterion is fulfilled first triggers the controlled stop of - and termination of GraGLeS. - - - - The simulation stops if the total number of grains - becomes smaller than this criterion. - - - - - The simulation stops if more iterations than this criterion have been computed. - - - - - - Configuration of numerical details of the solver. - - - - - Which type of convolution kernel and model is used. - - - - - - - - - - Constant to calibrate the real time scaling of the simulation. - - - - - - - Configuration of the grid coarsement algorithm whereby the representation - of the system is continuously rediscretized such that on average grains - are discretized with discretization many material points along each - direction. - - Grid coarsement can reduce the computational costs substantially although - it cannot be ruled out completely that the rediscretizing may have an effect - on the system evolution. Without grid coarsement the total number of material - points to consider stays the same throughout the simulation. - - - - Number of material points along each direction to discretize the - average grain. The larger this value is chosen the finer the curvature - details are that can be resolved but also the longer the simulation - takes. - - - - - If true grid coarsement is active, otherwise it is not. - - - - - Fraction how strongly the number of grains has to reduce - to trigger a grid coarsement step in an iteration. - - - - - - - Physically-based model of the assumed mobility of the grain boundaries. - - Grain boundary mobility is not an intrinsic property of a grain boundary but system-dependent - especially as grain boundaries in reality are decorated with defects as a consequence of which - the actual mobility is a combination of the mobility of the individual defects and the attached - boundary patches. Grain boundaries have different degrees of microscopic freedom. - Therefore, their mobility follows a distribution. - - - - - Fundamental model how :math:`m` is assumed a function of the disorientation - angle :math:`\Theta`. - - - - - - - - - The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed - temperature. GraGLeS was developed for modelling isothermal annealing. - - - - - Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. - - - - - - Mobility scaling factor :math:`c_2`. Typically 5. - - - - - Mobility scaling factor :math:`c_3`. Typically 9. - - - - - - Physically-based model of the assumed grain boundary surface energy. - - Like for the grain boundary mobility, defects cause a distribution of energies for the - patches of which the boundary is composed. In practice a too complicated dependency - of the energy and mobility model is observed as a function of the type and chemical - decoration of the defects. Therefore, simplifying assumptions are typically made. - - - - Fundamental type of assumption if energies are considered isotropic or not. - - - - - - - - - Fundamental model how :math:`\gamma` is assumed a function of the disorientation - angle :math:`\Theta`. - - - - - - - - Mean grain boundary surface energy that is assumed a function of the - disorientation angle :math:`\Theta` of the adjoining grains :math:`\gamma(\Theta)`. - This value factorizes the curvature_driving_force model. - - - - - - - A continuum-scale curvature of an interface causes the interface to - migrate towards the center of the curvature radius. - - - - If true the curvature_driving_force is considered, otherwise it is not. - - - - - - A continuum-scale difference of the stored elastic energy in dislocation - configurations across a grain boundary can exert a driving force on the - grain boundary such that the boundary migrates into the volume with the - higher stored elastic energy. - - - - If true the dislocation_driving_force is considered, otherwise it is not. - - - - - Prefactor :math:`0.5Gb^2` that factorizes the average - stored elastic energy per length dislocation line. - - - - - - In case of an applied magnetic field, a difference of the magnetic - susceptibility can exert a driving force on the grain boundary such that - the boundary migrates into the volume with the higher magnetic energy. - - - - If true the magnetic_driving_force is considered, otherwise it is not. - - - - - - - A triple line mediates the atomic arrangement differences between three - interface patches. Therefore, the triple line is a defect that may not - have the same mobility as adjoining grain boundaries and thus it may - exert what can be conceptualized as a drag (resistance) to the motion - of the adjoining interface patches. - - - - Assumed triple junction drag. - - - - - - diff --git a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml deleted file mode 100644 index 2f25c33a6..000000000 --- a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml +++ /dev/null @@ -1,295 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of summary statistic log entries. - - - - - Number of grains in the computer simulation. - - - - - Number of interfaces in the computer simulation. - - - - - Application definition for documenting results with GraGLeS. - - - - - - - - - - - Simulation ID as an alias to refer to this simulation. - - - - - Discouraged free-text field to add further details to the computation. - - - - - - - - - - - - - - Programs and libraries representing the computational environment - - - - - - - - - - - - - - - - - - - - - - - - - - - - Documentation of the spatiotemporal evolution - - - - - Summary quantities which are the result of some post-processing of the snapshot data - (averaging, integrating, interpolating) happening in for practical reasons though in while - running the simulation. Place used for storing descriptors from continuum mechanics - and thermodynamics at the scale of the entire ROI. - - - - Evolution of the recrystallized volume fraction over time. - - - - Evolution of the physical time not to be confused with wall-clock time or - profiling data. - - - - - - - - Iteration or increment counter. - - - - - How many crystals are distinguished. - Crystals are listed irrespective of the phase to which these are assigned. - - - - - - - - - - Which type of stress. - - - - - - - - Applied external stress tensor on the ROI. - - - - - - - - - - - - Which type of strain. - - - - - Applied external strain tensor on the ROI. - - - - - - - - - - - - Which type of deformation gradient. - - - - - - - - Applied deformation gradient tensor on the ROI. - - - - - - - - - - - - Applied external magnetic field on the ROI. - - - - - - - - - - - - - Applied external electrical field on the ROI. - - - - - - - - - - - - - - - - Simulated temperature for this snapshot. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Set of pairs of crystal_identifier for each interface. - - - - - - - - - - Mobility times surface energy density of the interface normalized - to the maximum such product of the interface set. - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml deleted file mode 100644 index a98be4dd4..000000000 --- a/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml +++ /dev/null @@ -1,244 +0,0 @@ - - - - - - - - How many texture components are distinguished, minimum is 1. - - - - - How many special texture components are distinguished if any. - - - - - Number of discrete orientations that are distributed across the grains. - - - - - Application definition for the configuration of the legacy (micro)structure generator - developed by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. - - * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ - * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ - * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ - * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ - - The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. - Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. - Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. - - - - - - - - - - The computational domain will be synthesized either as a square (for dimensionality = 2) - or a cube (for dimensionality = 3) with axis-aligned cuboidal parent grains. The domain is - discretized into material points using either square pixel or cubic voxel as the tessellating - unit cells. - - - - Two-dimensional or three-dimensional simulation. - - - - - - - - - Target value for the number of material points per equivalent - discrete diameter of the arithmetic average sub-grain. - - - - - Assumed space group of the material. - - - - - - - - - - - Target value for the number of grains. The actual domain size and grid will be configured - based on the choices for discretization, number_of_grains, and shape of these grains. - - - - - Target value for the average number of sub-grains per grain. - - - - - - If available used to define the sequence of relative extent of grains along the y (first value) - and z-axis (second value) assuming the relative shape along the x-axis is 1. If not provided, - the relative extent of the grains will be 1 one average along each axis (globulitic structure). - - - - - - - - - - In texture research component analyses set on the idea that properties - of grains different based on orientation with certain regions in orientation - space show similar trends like a different average dislocation density - or orientation_spread. - - - - The first entry is always the null model None which measn that an orientation - is not categorized as a special component. Examples for special components are - Dillamore, Copper, Cube, Y, P and Q. - - - - - - - - Bunge-Euler angle parameterization of the texture components - location in orientation space for which specifically different settings - should be configured. - - - - - - - - - Disorientation angle below which an orientation is categorized as one of the - components. - - - - - - - - - Dislocations are modelled as Rayleigh-distributed mean-field density that - can differ between but is constant within grains and sub-grains. - - - - The minimum and the maximum dislocation density to distribute across grains. - - - - - - - - - The minimum and the maximum dislocation density to distribute across sub-grains. - - - - - - - - - - - The variance of the dislocation density distribution across the grains. - - - - - - - - The variance of the dislocation density distribution across the sub-grains. - - - - - - - - - Orientations of the grains are sampled from a set of Bunge-Euler angle triplets. - Orientations of the sub-grains are sampled by scattering the orientation - of the (parent) grain and with optional Rayleigh-distributed scatter. - - - - Bunge-Euler angle parameterization of the texture components - location in orientation space for which specifically different settings - should be configured. - - - - - - - - - The variance of the disorientation of the sub-grain to their parent grain. - - - - - - - - - diff --git a/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml deleted file mode 100644 index 7d0dabed3..000000000 --- a/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml +++ /dev/null @@ -1,189 +0,0 @@ - - - - - - - - Number of material points along the edge of the square- or cube-shaped domain. - - - - - Number of crystals. - - - - - Application definition for the results of the legacy (micro)structure generator developed - by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. - - * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ - * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ - * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ - * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ - - The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. - Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. - Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. - - - - - - - - - - Discouraged free-text field to add further details to the computation. - - - - - - - - - - - - - - - Programs and libraries representing the computational environment - - - - - - - - - - - - - - Default plot showing the grid. - - - - - - - - Crystal identifier that was assigned to each material point. - - - - - - Material point barycentre coordinate along z direction. - - - - - - - Coordinate along z direction. - - - - - - Material point barycentre coordinate along y direction. - - - - - - - Coordinate along y direction. - - - - - - Material point barycentre coordinate along x direction. - - - - - - - Coordinate along x direction. - - - - - - - - - - - - - - - - - - - - - - - - - - True if the crystal is considered a sub-grain. - False if the crystal is considered a grain. - - - - - - - - Bunge-Euler angle orientation of each crystal. - - - - - - - - - Mean-field dislocation density as a measure of the stored elastic energy - content that is stored in the dislocation network of this grain and related - defects within each crystal. - - - - - - - - - diff --git a/contributed_definitions/NXmicrostructure_ipf.nxdl.xml b/contributed_definitions/NXmicrostructure_ipf.nxdl.xml deleted file mode 100644 index 38256637b..000000000 --- a/contributed_definitions/NXmicrostructure_ipf.nxdl.xml +++ /dev/null @@ -1,243 +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. - - - - - Base class to store an inverse pole figure (IPF) mapping (IPF map). - - - - Reference to an :ref:`NXcoordinate_system` in which the projection_direction is defined. - - If the field depends_on is not provided but parents of the instance of this base class or its - specializations define an instance of :ref:`NXcoordinate_system`, projection_direction - is defined in this coordinate system. - - If nothing is provided it is assumed that projection_direction is defined in the McStas coordinate system. - - - - - The direction along which orientations are projected. - - - - - - - - Details about the original grid. - - Here original grid means the grid for which the IPF map was computed when that - IPF map was exported from the tech partner's file format representation. - - - - - Details about the grid onto which the IPF is recomputed. - - Rescaling the visualization of the IPF map may be needed to enable - visualization in specific software tools like H5Web. - - - - - How where orientation values at positions of input_grid computed to values on output_grid. - - Nearest neighbour means the orientation of the closed (Euclidean distance) grid point of the input_grid was taken. - - - - - - - - Inverse pole figure mapping. - - 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:`NXmicrostructure_ipf`, to bring colleagues - and users of IPF maps together to discuss which pieces of information need storage. - - We are convinced a step-by-step design and community-driven discussion is a practical - strategy to work towards an interoperable description and data model for exchanging - IPF maps as a specific community-accepted method to convey orientation maps. - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is one common understanding which enables also those users who are - not necessarily experts in all the details of the underlying techniques an - understanding if the dataset is worth to become reused or repurposed. - - - - - - Inverse pole figure color code for each map coordinate. - - - - - - - - - - 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 to orientation in the fundamental zone. - - For each stereographic standard triangle (SST), i.e. a rendering of the - fundamental zone of the crystal-symmetry-reduced orientation space - SO3, it is possible to define a color model which assigns a color to each - point in the fundamental zone. - - Different mapping models are used. These implement (slightly) different - scaling relations. Differences exist across representations of tech partners. - - Differences are which base colors of the RGB color model are placed in - which extremal position of the SST and where the white point is located. - - For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * [S. Patala et al.](https://doi.org/10.1016/j.pmatsci.2012.04.002). - - Details are implementation-specific and not standardized yet. - - Given that the SST has a complicated geometry, it can not yet be - visualized using tools like H5Web, which is why for now the matrix - of a rasterized image which is rendered by the backend tool gets - copied into an RGB matrix to offer a default plot. - - - - - - Inverse pole figure color code for each map coordinate. - - - - - - - - - - Pixel along the y-axis. - - - - - - - - - Pixel along the x-axis. - - - - - - - - - diff --git a/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml deleted file mode 100644 index 5b85f6473..000000000 --- a/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml +++ /dev/null @@ -1,193 +0,0 @@ - - - - - - - - Number of material points along the z axis of the domain. - - - - - Number of material points along the y axis of the domain. - - - - - Number of material points along the x axis of the domain. - - - - - Number of crystals. - - - - - Application definition for the microstructure generator kanapy from ICAMS Bochum. - - * `A. Hartmeier et al. <https://joss.theoj.org/papers/10.21105/joss.01732>`_ - - A draft application definition to support discussion within the infrastructure use case IUC07 of the - NFDI-MatWerk consortium of the German NFDI working on a data model for documenting simulations - of spatiotemporal microstructure evolution with scientific software from this community. - - - - - - - - - - Discouraged free-text field to add further details to the computation. - - - - - - - - - - - - - - - - - - - - - - Programs and libraries representing the computational environment - - - - - - - - - - - - - - - - - Default plot showing the grid. - - - - - - - - Crystal identifier that was assigned to each material point. - - - - - - Material point barycentre coordinate along z direction. - - - - - - - Coordinate along z direction. - - - - - - Material point barycentre coordinate along y direction. - - - - - - - Coordinate along y direction. - - - - - - Material point barycentre coordinate along x direction. - - - - - - - Coordinate along x direction. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bunge-Euler angle orientation of each crystal. - - - - - - - - - - diff --git a/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml b/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml deleted file mode 100644 index 2dae22c98..000000000 --- a/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml +++ /dev/null @@ -1,321 +0,0 @@ - - - - - - - - Number of entries in the default color map - - - - - Number of entries in color map - - - - - 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/NXmicrostructure_odf.nxdl.xml b/contributed_definitions/NXmicrostructure_odf.nxdl.xml deleted file mode 100644 index 764e0ab77..000000000 --- a/contributed_definitions/NXmicrostructure_odf.nxdl.xml +++ /dev/null @@ -1,224 +0,0 @@ - - - - - - - - Number of pixel per varphi section plot along the :math:`\varphi_1` fastest - direction. - - - - - Number of pixel per varphi section plot along the :math:`\Phi` fast direction. - - - - - Number of pixel per varphi section plot along the :math:`\varphi_2` slow - direction. - - - - - Number of local maxima evaluated in the component analysis. - - - - - Number of sampled positions in orientation space. - - - - - Base class to store an orientation distribution function (ODF). - - An orientation distribution function is a probability distribution that details how - much volume of material has a specific orientation. An ODF is computed from - pole figure data in a computational process called `pole figure inversion <https://doi.org/10.1107/S0021889808030112>`_. - - - - Details about the algorithm used for computing the ODF. - - - - Point group of the crystal structure of the phase for which the here documented phase- - dependent ODF was computed.(following the notation of the International Table of Crystallography). - - - - - Point group assumed for additionally considered sample symmetries - following the notation of the International Table of Crystallography). - - - - - Halfwidth of the kernel. - - - - - Name of the kernel. - - - - - Resolution of the kernel. - - - - - - - Group to store descriptors and summary statistics for extrema of the ODF. - - - - Minima or maxima, if extrema is set to minima values for location and volume_fraction - are sorted in increasing order. If extrema is set to maxima values for location and - volume_fraction are sorted in descreasing order. Therefore, the global extremum is - always the first entry in location and volume_fraction. - - - - - - - - - Number of local extrema evaluated - - - - - - Disorientation threshold within which intensity of the ODF - is integrated for the component analysis. - - - - - Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the kth-most - maxima in decreasing order of the intensity maximum. - - - - - - - - - Integrated ODF intensity within a theta angular region of the orientation space (SO3) - about each location (obeying symmetries) as specified for each location. - - - - - - - - - The ODF intensity values (weights) as sampled with a software - - - - Sampling resolution - - - - - Bunge-Euler (i.e. ZXZ convention) locations of each position - in orientation space for which a weight was sampled. - - - - - - - - - Weight at each sampled position following the order in euler. - - - - - - - - - Visualization of the ODF intensity as discretized orthogonal sections through - orientation space parameterized using Bunge-Euler angles. - - This is one example of typical default plots used in the texture community in materials engineering. - - Mind that when parameterized using Euler angles the orientation space is a distorted space. - Therefore, equivalent orientations show intensity contributions in eventually multiple locations. - - - - - ODF intensity at probed locations relative to the intensity of the null model of - a random texture. - - - - - - - - - - Pixel center angular position along the :math:`\varphi_1` direction. - - - - - - - - - Pixel center angular position along the :math:`\Phi` direction. - - - - - - - - - Pixel center angular position along the :math:`\varphi_2` direction. - - - - - - - - diff --git a/contributed_definitions/NXmicrostructure_pf.nxdl.xml b/contributed_definitions/NXmicrostructure_pf.nxdl.xml deleted file mode 100644 index 01804b54b..000000000 --- a/contributed_definitions/NXmicrostructure_pf.nxdl.xml +++ /dev/null @@ -1,114 +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. - - A pole figure is the X-ray diffraction intensity for specific integrated - peaks for a hemispherical illumination of a real or virtual specimen. - - - - Details about the algorithm that was used to compute the pole figure. - - - - Point group of the crystal structure of the phase for which the pole figure - was computed (according to International Table of Crystallography). - - - - - Point group of assumed sample symmetries (according to International Table of - Crystallography). - - - - - - Halfwidth of the kernel. - - - - - Miller indices (:math:`(hkl)[uvw]`) to specify the pole figure. - - - - - Resolution of the kernel. - - - - - - Pole figure. - - - - - Pole figure intensity. - - - - - - - - - Pixel center along y direction in the equatorial plane of - a stereographic projection of the unit sphere. - - - - - - - - - Pixel center along x direction in the equatorial plane of - a stereographic projection of the unit sphere. - - - - - - - - diff --git a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml deleted file mode 100644 index 1e9283c97..000000000 --- a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml +++ /dev/null @@ -1,543 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of summary statistic log entries. - - - - - Number of boundaries of the bounding box or primitive to domain. - - - - - Number of parameter required for chosen orientation parameterization. - - - - - Number of texture components identified. - - - - - Dimensionality. - - - - - Cardinality. - - - - - Number of active cells in the (recrystallization) front. - - - - - Number of grains in the computer simulation. - - - - - Application definition for storing results of the SCORE cellular automaton. - - The SCORE cellular automaton model for primary recrystallization is an - example of typical materials engineering applications used within the field - of so-called Integral Computational Materials Engineering (ICME) whereby - one can simulate the evolution of microstructures. - - Specifically the SCORE model can be used to simulate the growth of static - recrystallization nuclei. The model is described in the literature: - - * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ - * `C. Haase et al. <https://doi.org/10.1016/j.actamat.2015.08.057>`_ - * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ - - - - - - - - - - Simulation ID as an alias to refer to this simulation. - - - - - Discouraged free-text field to add further details to the computation. - - - - - - - - - - - - - - Programs and libraries representing the computational environment - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A tight bounding box or sphere or bounding primitive about the grid. - - - - - How many distinct boundaries are distinguished? - Most grids discretize a cubic or cuboidal region. In this case - six sides can be distinguished, each making an own boundary. - - - - - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet - - - - - - - - Name of the boundaries. Left, right, front, back, bottom, top, - The field must have as many entries as there are number_of_boundaries. - - - - - - - - - - Documentation of the spatiotemporal evolution - - - - - Summary quantities which are the result of some post-processing of the snapshot data - (averaging, integrating, interpolating) happening in for practical reasons though in while - running the simulation. Place used for storing descriptors from continuum mechanics - and thermodynamics at the scale of the entire ROI. - - - - Evolution of the recrystallized volume fraction over time. - - - - Evolution of the physical time not to be confused with wall-clock time or - profiling data. - - - - - - - - Iteration or increment counter. - - - - - Evolution of the simulated temperature over time. - - - - - - - - Recrystallized volume fraction. - - - - - - - - - - Which type of stress. - - - - - - - - Applied external stress tensor on the ROI. - - - - - - - - - - - - Which type of strain. - - - - - Applied external strain tensor on the ROI. - - - - - - - - - - - - Which type of deformation gradient. - - - - - - - - Applied deformation gradient tensor on the ROI. - - - - - - - - - - - - Applied external magnetic field on the ROI. - - - - - - - - - - - - - Applied external electrical field on the ROI. - - - - - - - - - - - - - - - - Simulated temperature for this snapshot. - - - - - Current recrystallized volume fraction (taking fractional infections into - account). - - - - - Target value for which a snapshot was requested for the recrystallized volume - fraction. - - - - - - - Grain identifier for each cell. - - - - - - - - - - Identifier of the OpenMP thread which processed this part of the grid. - - - - - - - - - - - - - - - - - - - - - - - - - - - Volume of each grain accounting also for partially transformed cells. - - - - - - - - - Bunge-Euler angle triplets for each grain. - - - - - - - - - Current value for the dislocation density as a measure of the remaining stored energy - in assumed crystal defects inside each grain. - - - - - - - - Is the grain deformed. - - - - - - - - Is the grain recrystallized. - - - - - - - - - Details about those cells which in this time step represent the discrete - recrystallization front. - - - - Which cells are currently in a halo region of threads. - - - - - - - - So-called mobility weight which is a scaling factor to - control the mobility of the grain boundary which is assumed - to sweep currently this volume. - - - - - - - - The x, y, z grid coordinates of each cell in the recrystallization front. - - - - - - - - - Grain identifier assigned to each cell in the recrystallization front. - - - - - - - - Grain identifier assigned to each nucleus which affected that cell in the - recrystallization front. - - - - - - - - Identifier of the OpenMP thread processing each cell in the recrystallization - front. - - - - - - - - Hint about the direction from which the cell was infected. - - - - - - - - - - - diff --git a/contributed_definitions/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.nxdl.xml b/contributed_definitions/NXms.nxdl.xml new file mode 100644 index 000000000..75a010f88 --- /dev/null +++ b/contributed_definitions/NXms.nxdl.xml @@ -0,0 +1,529 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of boundaries of the bounding box or primitive to domain. + + + + + Number of parameter required for the chosen orientation parameterization. + + + + + Number of texture components identified. + + + + + Application definition, spatiotemporal characterization of a microstructure. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment or computer simulation. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the workflow (experiment/analysis/simulation). + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of this application definition rather than write details about the + experiment into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the characterization started. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the characterization ended. + + + + + + + + + + Specify if the (characterization) results/data of this instance of an + application definition are based on the results of a simulation or the + results of a post-processing of measured data to describe + a microstructure. + + The term microstructure is used to describe the spatial arrangement of + crystal defects inside a sample/specimen without demanding necessarily + that this structure is mainly at the micron length scale. + Nanostructure and macrostructure are close synonyms. + Material architecture is a narrow synonym. + + Given that microstructure simulations nowadays more and more consider + the atomic arrangement, this application definition can also be used + to describe features at the scale of atoms. + + + + + + + + + Contact information and eventually details of at least one person + involved in creating this result. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + A least a right-handed Cartesian coordinate system with base vectors + named x, y, and z has to be specified. Each base vector of the + coordinate system should be described with an NXtransformations instance. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The simulated or characterized material volume element aka domain. + At least one instance of geometry required either NXcg_grid, + NXcg_polyhedron_set, or NXcg_point_set. This geometry group needs + to contain details about the boundary conditions. + + + + + + + + A boundary to the volume element. + Either an instance of NXcg_hexahedron_set or of NXcg_ellipsoid_set. + + + + + How many distinct boundaries are distinguished. Value required equal to n_b. + + + + + Name of the boundaries. E.g. left, right, front, back, bottom, top, + + + + + + + + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + + + + + + + + + Collection of microstructural data observed/simulated. + + + + Integer which specifies the first index to be used for distinguishing + snapshots. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate + if the identifiers are expected to start from 1 (referred to as + Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index + notation) respectively. + + + + + + Summary quantities which are the result of some post-processing of + the snapshot data (averaging, integrating, interpolating). + Frequently used descriptors from continuum mechanics and thermodynamics + can be used here. A few examples are given. Each descriptor is currently + modelled as an instance of an NXprocess because it is relevant to + understand how the descriptors are computed. + + + + + + + + + + + + + + Measured or simulated physical time stamp for this snapshot. + Not to be confused with wall-clock timing or profiling data. + + + + + Iteration or increment counter. + + + + + + + + + + Conceptually distinguished object/feature in the ROI/ + system with some relevance. Instances of NXms_feature_set can + be nested to build a hierarchy of logically-related objects. + + A typical example for MD simulations is to have one + ms_feature_set for the atoms which is the parent to another + ms_feature_set for monomers/molecules/proteins which is then the + parent to another ms_feature_set for the secondary, another feature_set + for the tertiary, and the parent for another feature_set for the + quaternary structure. + + Another typical example from materials engineering is to have + one ms_feature_set for crystals (grains/phases) which serves as + the parent to another ms_feature_set for interfaces between these + crystals which then is the parent for another ms_feature_set to + describe the triple junctions which is then the parent for the + quadruple/higher-order junctions between which connect the + triple lines. + + Another example from discrete dislocation dynamics could be to + have one ms_feature_set for the dislocations (maybe separate + sets for each dislocation type or family) which are then + parents to other ms_feature_set which describe junctions between + dislocations or features along the dislocation line network. + + + + + + Details about the orientation distribution function + within the entire domain. + + + + With which method was the ODF approximated? + + + + + + TO BE DEFINED + + + + + TO BE DEFINED + + + + + Collection of texture components commonly referred to. + + + + Reference to or definition of a coordinate system with + which the definitions are interpretable. + + + + + + + + + + + Parameterized orientations. + + + + + + + + + Name of each texture component, e.g. Cube, Dillamore, Y. + + + + + + + + The portion of orientation space integrated over + to compute the volume fraction. + + + + + + + + The volume fraction of each texture component. + + + + + + + + + + + Details about the disorientation distribution function + within the entire domain. + + + + + Details about the grain boundary character distribution + within the entire domain. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXms_feature_set.nxdl.xml b/contributed_definitions/NXms_feature_set.nxdl.xml new file mode 100644 index 000000000..326d8cc54 --- /dev/null +++ b/contributed_definitions/NXms_feature_set.nxdl.xml @@ -0,0 +1,300 @@ + + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Dimensionality + + + + + Cardinality/number of members/features in the feature set. + + + + + Number of types in the dictionary of human-readable types of features. + + + + + Total number of parent identifier. + + + + + Set of topological/spatial features in materials build from other features. + + + + + + Name (or link?) to another NXms_feature_set which defines features what are + assumed as the parents/super_features of all members in this feature set. + If depends_on is set to "." or this attribute is not defined in an instance + of this application definition, assume that this feature_set instance + represents the root feature_set of the feature tree/graph. + + + + + + + What is the best matching description how dimensional the feature is. + + + + + + + + + + + + How many features/members are in this set? + + + + + + The keywords of the dictionary of human-readable types of features. + Using terms from a community-agreed upon controlled vocabulary, e.g. + atom, solute, vacancy, monomer, molecule, anti-site, crowd_ion, + quadruple junction, triple line, disconnection, dislocation, + kink, jog, stacking_fault, homo_phase_boundary, hetero_phase_boundary, + surface, thermal_groove_root, precipitate, dispersoid, pore, crack + is recommended. + + + + + + + + + The integer identifier used to resolve of which type each feature is, + i.e. the values of the dictionary of human-readable types of features. + + + + + + + + For each feature in the set specify the associated number of identifier + to parent features as are resolvable via depends_on. + This array enables to compute the array interval from which details for + specific features can be extracted as if they would be stored in an own + group. + + + + + + + + Concatenated array of parent identifier for each feature (in the sequence) + according to identifier and how the identifier of features in the here + described feature set are defined (implicitly from 0, to c-1 or via explicit + identifier. + + + + + + + + + Integer which specifies the first index to be used for distinguishing + features. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish features for explicit indexing. + + + + + + + + + Assumptions and parameter to arrive at geometric primitives + to locate zero-dimensional/point-(like) features which are + discretized/represented by points. + + + + + Assumptions, parameters, and details how positional uncertainty + of the geometry is quantified. + + + + + + + Assumptions and parameters to arrive at geometric primitives + to locate one-dimensional/line-like features which are + discretized by polylines. + + + + + + Assumptions, parameters, and details how positional uncertainty + of the geometry is quantified. + + + + + + Assumptions and parameters to arrive at geometric primitives + to locate two-dimensional/interface features which are + discretized by triangulated surface meshes. + + + + + + Assumptions, parameters, and details how positional uncertainty + of the geometry is quantified. + + + + + + Assumptions and parameters to arrive at geometric primitives + to locate three-dimensional/volumetric features which are + discretized by triangulated surface meshes of polyhedra. + + + + + + Assumptions, parameters, and details how positional uncertainty + of the geometry is quantified. + + + + + + + + + + diff --git a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml b/contributed_definitions/NXms_score_config.nxdl.xml similarity index 53% rename from contributed_definitions/NXmicrostructure_score_config.nxdl.xml rename to contributed_definitions/NXms_score_config.nxdl.xml index 082293a3e..7aab8367c 100644 --- a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml +++ b/contributed_definitions/NXms_score_config.nxdl.xml @@ -1,10 +1,10 @@ - + - + @@ -33,27 +33,6 @@ Number of Bunge-Euler angle triplets for recrystallization nuclei. - - - Number of support points for the linearized drag profile. - - - - - Number of suport points for the desired time-temperature profile. - - - - - Number of entries when to defragment i.e. garbage collect the memory holding - state information for recrystallized cells. - - - - - Number of entries when to collect snapshots of the evolving microstructure. - - Number of solitary unit domains to export. @@ -61,72 +40,59 @@ - Application definition to configure a simulation with the SCORE model. - - * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ - * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ + Application definition to control a simulation with the SCORE model. - - - - - - + - Simulation ID as an alias to refer to this simulation. + Version specifier of this application definition. - - + + - Discouraged free-text field to add further details to the computation. + Official NeXus NXDL schema with which this file was written. + + + - - - - - + - - + - Programs and libraries representing the computational environment + Ideally, a (globally persistent) unique identifier for referring + to this analysis. - - - - - - - + + + + Possibility for leaving a free-text description about this analysis. + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + Relevant data to instantiate a starting configuration that is typically a microstructure in deformed conditions where stored (elastic) energy is stored in the form of crystal defects, which in the SCORE model are is considered as mean-field dislocation content. - - - - Extend of each CA domain in voxel along the x, y, and z direction. - Deformation of sheet material is assumed. - The x axis is assumed pointing along the rolling direction. - The y axis is assumed pointing along the transverse direction. - The z axis is assumed pointing along the normal direction. - - - - - - - - Details how the deformed grains should be modelled. - - + Which model should be used to generate a starting microstructure. @@ -137,43 +103,66 @@ - + + + Edge length of the cubic cells of each CA domain. + + + + + Extend of each CA domain in voxel along the x, y, and z direction. + Deformation of sheet material is assumed. + The x axis is assumed pointing along the rolling direction. + The y axis is assumed pointing along the transverse direction. + The z axis is assumed pointing along the normal direction. + + + + + + - Extent of each deformed grain in voxel along the - x, y, and z direction when type is cuboidal. + Extent of each deformed grain along the x, y, and z direction when type is + cuboidal. - + Average spherical diameter when type is poisson_voronoi. - + - Set of Bunge-Euler angles ( :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) - to sample orientations of deformed grains randomly from. + Set of Bunge-Euler angles to sample orientations randomly from. - + - The EBSD dataset from which the initial microstructure is - instantiated if model is ebsd. + The EBSD dataset from which the initial microstructure is instantiated + if initial_microstructure/type has value ebsd. - - - - + + + Path and name of the EBSD dataset from which to generate the starting + microstructure. + + + + SHA256 checksum of the file which contains the EBSD dataset. + + + - Extent of the pixel of the EBSD orientation mapping assuming square-shaped - pixels. + Size of the EBSD. The EBSD orientation mapping has to be on a + regular grid of square-shaped pixels. @@ -181,18 +170,17 @@ - + - Phenomenological model according to which recrystallization nuclei - are placed into the domain and assumed growing. + Phenomenological model according to which it nuclei are placed + into the domain and assumed growing. - + - According to which model will the nuclei become distributed spatially: - - * csr, complete spatial randomness. - * custom, implementation specific. - * gb, nuclei placed at grain boundaries + According to which model will the nuclei become distributed spatially. + CSR means complete spatial randomness. + Custom is implementation specific. + GB places nuclei at grain boundaries. @@ -200,7 +188,7 @@ - + According to which model will the nuclei start to grow. @@ -208,7 +196,7 @@ - + According to which model will the nuclei get their orientation assigned. @@ -216,10 +204,9 @@ - + - Set of Bunge-Euler angles ( :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) - to sample orientations of nuclei randomly from. + Set of Bunge-Euler angles to sample orientations of nuclei randomly from. @@ -227,11 +214,10 @@ - + - (Mechanical) properties of the material which scale - the amount of stored (elastic) energy in the system and - thus mainly affect recrystallization kinetics. + (Mechanical) properties of the material which scale the amount + of stored (elastic) energy in the ROI/system. @@ -253,98 +239,42 @@ SecondOrderThermalExpCoeff--> - + - Model for the assumed mobility of grain boundaries with different disorientation - essentially implementing variations of Turnbull's model for - thermally-activated migration. + Model for the assumed mobility of grain boundaries with different + disorientation. - Which type of fundamental model for the grain boundary mobility. - - Grain boundaries with disorientation angle smaller than 15 degree are considered - as low-angle grain boundaries. Other grain boundaries are high-angle boundaries. + Which type of fundamental model for the grain boundary mobility: + For the Sebald-Gottstein model the following equation is used. + For the Rollett-Holm model the following equation is used. - - - - Parameter of the Sebald-Gottstein migration model. - - - - At which disorientation angle are grain boundary considered as high-angle grain - boundaries. - - - - - Pre-exponential factor for low-angle grain boundaries. - - - - - Migration activation enthalpy for low-angle grain boundaries. - - - - - Pre-exponential factor for high-angle grain boundaries. - - - - - Migration activation enthalpy for high-angle grain boundaries. - - - - - Pre-exponential factor for particularly mobile boundaries. - - - - - Migration activation enthalpy for particularly mobile boundaries. - - + + + + + + + - - - Parameter of the Rollett-Holm migration model. - - - - - The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed - temperature. GraGLeS was developed for modelling isothermal annealing. - - - - - Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. - - - - - Mobility scaling factor :math:`c_2`. Typically 5. - - - - - Mobility scaling factor :math:`c_3`. Typically 9. - - + + + + + + - + - Time-dependent reduction of the stored (elastic) energy to account for recovery. + Simulated evolution of the dislocation density as the stored + (elastic) energy assumed stored in each grain. @@ -355,10 +285,11 @@ TODO: add equation for the Rollett-Holm model the following equation--> - + - Reduction of the grain boundary migration speed due to the presence of dispersoids - through which the total grain boundary area of the recrystallization front can be reduced. + Simulated reduction of the grain boundary speed due to + the presence of dispersoids through which the total grain boundary + area of the recrystallization front can be reduced. @@ -369,28 +300,16 @@ TODO: add equation for the Rollett-Holm model the following equation--> - - - Parameter of the Zener-Smith drag model. - - - - Configuration-dependent constant which factorizes the drag pressure. - - - - - Average surface energy of the grain-boundary-dispersoid-surface configuration - which factorizes the drag pressure. - - + + + Support point of the linearized curve of simulated time matching a specific support point of the average dispersoid radius. - + @@ -398,14 +317,14 @@ TODO: add equation for the Rollett-Holm model the following equation--> Support point of the linearized curve of the average dispersoid radius. - + - + - Desired simulated time-temperature profile + Simulated time temperature profile @@ -413,19 +332,19 @@ TODO: add equation for the Rollett-Holm model the following equation--> a specific support point of the temperature. - + - + Support point of the linearized curve of the temperature. - + - + Criteria which enable to stop the simulation in a controlled manner. Whichever criterion is fulfilled first stops the simulation. @@ -446,7 +365,7 @@ TODO: add equation for the Rollett-Holm model the following equation--> - + Settings relevant for stable numerical integration. @@ -467,7 +386,7 @@ TODO: add equation for the Rollett-Holm model the following equation--> By how much more times should the already allocated memory - be increased to offer space for storing states of cells + be is increased to offer space for storing states of cells in the recrystallization front. @@ -484,32 +403,20 @@ TODO: add equation for the Rollett-Holm model the following equation--> will be defragmented on-the-fly. - + - - - + List of recrystallized volume target values at which a - snapshot of the CA state should be stored. - - The code documents summary statistics like recrystallized volume fraction - for each iteration. However, snapshots of the microstructure can take much - space as SCORE is able to evolve automata with up to :math:`1600^3` cells. - Snapshot data document the current microstructure which includes the grain - assigned to each of these cells plus the state of the recrystallization front. - - Despite these front data make up for approximately one order of magnitude - less cells than represented in the domain, more numerical data have to be - collected each cell in the front than just a grain identifier. + snapshot of the CA state should be exported for. - + - + Perform a statistical analyses of the results as it was @@ -538,5 +445,8 @@ TODO: add equation for the Rollett-Holm model the following equation--> + + + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml new file mode 100644 index 000000000..0e957612e --- /dev/null +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -0,0 +1,720 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of boundaries of the bounding box or primitive to domain. + + + + + Number of parameter required for chosen orientation parameterization. + + + + + Number of texture components identified. + + + + + Dimensionality. + + + + + Cardinality. + + + + + Number of active cells in the (recrystallization) front. + + + + + Number of grains in the computer simulation. + + + + + Application definition for storing results of the SCORE cellular automaton. + + The SCORE cellular automaton model for primary recrystallization is an + example of typical materials engineering applications used within the field + of so-called Integral Computational Materials Engineering (ICME) whereby + one can simulate the evolution of microstructures. + + Specifically the SCORE model can be used to simulate the growth of static + recrystallization nuclei. The model is described in the literature: + + * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ + * `C. Haase et al. <https://doi.org/10.1016/j.actamat.2015.08.057>`_ + * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this computer simulation. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the workflow (analysis/simulation). + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of this application definition rather than write details about the + experiment into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the characterization started. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the characterization ended. + + + + + + + + + + Specify if the (characterization) results/data of this instance of an + application definition are based on the results of a simulation or the + results of a post-processing of measured data to describe a microstructure. + The term microstructure is used to describe the spatial arrangement of + crystal defects inside a sample/specimen without demanding necessarily + that this structure is mainly at the micron length scale. + Nanostructure and macrostructure are close synonyms. + Material architecture is a narrow synonym. + + + + + + + + + + The path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the SCORE executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + Contact information and eventually details of at least one person + involved in creating this result. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + A least a right-handed Cartesian coordinate system with base vectors + named x, y, and z has to be specified. Each base vector of the + coordinate system should be described with an NXtransformations instance. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The simulated or characterized material volume element aka domain. + At least one instance of geometry required either NXcg_grid, + NXcg_polyhedron_set, or NXcg_point_set. This geometry group needs + to contain details about the boundary conditions. + + + + + + + + + + + + + A tight bounding box or sphere or bounding primitive about the grid. + + + + + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. + + + + + Name of the boundaries. E.g. left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. + + + + + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + + + + + + + + + Collection of microstructural data observed/simulated. + + + + Integer which specifies the first index to be used for distinguishing + snapshots. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate + if the identifiers are expected to start from 1 (referred to as + Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index + notation) respectively. + + + + + + Summary quantities which are the result of some post-processing of + the snapshot data (averaging, integrating, interpolating). + Frequently used descriptors from continuum mechanics and thermodynamics + can be used here. A few examples are given. Each descriptor is currently + modelled as an instance of an NXprocess because it is relevant to + understand how the descriptors are computed. + + + + Evolution of the physical time. + + + + + Evolution of the simulated temperature over time. + + + + + + Evolution of the recrystallized volume fraction over time. + + + + + + + + Measured or simulated physical time stamp for this snapshot. + Not to be confused with wall-clock timing or profiling data. + + + + + Simulated temperature. + + + + + Iteration or increment counter. + + + + + + + Grain identifier for each cell. + + + + + + + + + + Identifier of the OpenMP thread which processed this part of the grid. + + + + + + + + + + + + Details about those cells which in this time step represent + the discretized recrystallization front. + + + + Which cells are currently in a halo region of threads. + + + + + + + + So-called mobility weight which is a scaling factor to + control the mobility of the grain boundary which is assumed + to sweep currently this volume. + + + + + + + + Grid coordinates of each cell in the recrystallization front. + + + + + + + + + Grain identifier assigned to each cell in the recrystallization front. + + + + + + + + Grain identifier assigned to each nucleus which affected that cell in the + recrystallization front. + + + + + + + + Relative volume transformed as a measure of infection progress. + + + + + + + + Identifier of the OpenMP thread processing each cell in the recrystallization + front. + + + + + + + + Hint about the direction from which the cell was infected. + + + + + + + + + Current grain-related quantities. + + + + Bunge-Euler angle triplets for each grain. + + + + + + + + + Discrete volume of each grain accounting also for partially + transformed cells. + + + + + + + + Current value for the dislocation density as a measure of + the remaining stored energy in assumed crystal defects inside + each grain. The difference between these values scales the + driving force of grain boundary migration. + + + + + + + + Is the grain deformed. + + + + + + + + Is the grain recrystallized. + + + + + + + + + Current recrystallized volume fraction. + + + + Currently evaluated actual recrystallized volume fraction. + This takes into account partially recrystallized cells. + + + + + Currently desired target recrystallized volume fraction at + which the user requested to log a snapshot. + + + + + + + + Currently assumed globally applied Cauchy stress tensor on the ROI. + + + + + + + + + + + Currently assumed globally applied Cauchy strain tensor on the ROI. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 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/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXms_snapshot.nxdl.xml similarity index 54% rename from base_classes/NXcg_sphere_set.nxdl.xml rename to contributed_definitions/NXms_snapshot.nxdl.xml index 8b1283474..1f922e281 100644 --- a/base_classes/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXms_snapshot.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. - - - Computational geometry description of a set of spheres. - - Each sphere can have a different radius but all need to have finite volume. + Base class for data on the state of the microstructure at a given + time/iteration. - + + + Is this time for a measurement or a simulation. + + + + + + + - In the case that all spheres have the same radius. + Measured or simulated physical time stamp for this snapshot. + Not to be confused with wall-clock timing or profiling data. - + - In the case that spheres have different radius use this - instead of the radius field. + Iteration or increment counter. - - - diff --git a/contributed_definitions/NXms_snapshot_set.nxdl.xml b/contributed_definitions/NXms_snapshot_set.nxdl.xml new file mode 100644 index 000000000..6cff36cc3 --- /dev/null +++ b/contributed_definitions/NXms_snapshot_set.nxdl.xml @@ -0,0 +1,62 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + A collection of spatiotemporal microstructure data. + + + + Is this set describing a measurement or a simulation? + + + + + + + + + Integer which specifies the first index to be used for distinguishing + snapshots. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + + diff --git a/contributed_definitions/NXopt.nxdl.xml b/contributed_definitions/NXopt.nxdl.xml new file mode 100644 index 000000000..be636590f --- /dev/null +++ b/contributed_definitions/NXopt.nxdl.xml @@ -0,0 +1,868 @@ + + + + + + + + + Variables used throughout the document, e.g. dimensions or parameters. + + + + Length of the spectrum array (e.g. wavelength or energy) of the measured + data. + + + + + Number of sensors used to measure parameters that influence the sample, + such as temperature or pressure. + + + + + Number of measurements (1st dimension of measured_data array). This is + equal to the number of parameters scanned. For example, if the experiment + was performed at three different temperatures and two different pressures + N_measurements = 2*3 = 6. + + + + + Number of detection angles of the beam reflected or scattered off the + sample. + + + + + Number of angles of incidence of the incident beam. + + + + + Number of observables that are saved in a measurement. e.g. one for + intensity, reflectivity or transmittance, two for Psi and Delta etc. This + is equal to the second dimension of the data array 'measured_data' and the + number of column names. + + + + + An application definition for optical spectroscopy experiments. + + + + An application definition template for optical spectroscopy experiments. + + A general optical experiment consists of a light or excitation source, a + beam path, a sample + its stage + its environment, and a detection unit. + Examples are reflection or transmission measurements, photoluminescence, + Raman spectroscopy, ellipsometry etc. + + + + An application definition describing a general optical experiment. + + + + Version number to identify which definition of this application + definition was used for this entry/data. + + + + + URL where to find further material (documentation, examples) relevant + to the application definition. + + + + + + + + + A (globally persistent) unique identifier of the experiment. + (i) The identifier is usually defined by the facility or principle + investigator. + (ii) The identifier enables to link experiments to e.g. proposals. + + + + + An optional free-text description of the experiment. + + However, details of the experiment should be defined in the specific + fields of this application definition rather than in this experiment + description. + + + + + Specify the type of the optical experiment. + + + + + Start time of the experiment. UTC offset should be specified. + + + + + Contact information of at least the user of the instrument or the + investigator who performed this experiment. + Adding multiple users, if relevant, is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the + experiment was performed. + + + + + Street address of the user's affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + Telephone number of the user. + + + + + + Properties of the experimental setup. This includes general information + about the instrument (such as model, company etc.), information about + the calibration of the instrument, elements of the beam path including + the excitation or light source and the detector unit, the sample stage + (plus the sample environment, which also includes sensors used to + monitor external conditions) and elements of the beam path. + + Meta data describing the sample should be specified in ENTRY/SAMPLE + outside of ENTRY/INSTRUMENT. + + + + The name of the instrument. + + + + The used version of the hardware if available. If not a commercial + instrument use date of completion of the hardware. + + + + + + Name of the company which build the instrument. + + + + + ISO8601 date when the instrument was constructed. + UTC offset should be specified. + + + + + + Commercial or otherwise defined given name of the program that was + used to measure the data, i.e. the software used to start and + record the measured data and/or metadata. + If home written, one can provide the actual steps in the NOTE + subfield here. + + + + + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + + + + Website of the software. + + + + + + Commercial or otherwise defined name of the firmware that was used + for the measurement - if available. + + + + Version and build number or commit hash of the software source code. + + + + + Website of the software. + + + + + + Was a calibration performed? If yes, when was it done? If the + calibration time is provided, it should be specified in + ENTRY/INSTRUMENT/calibration/calibration_time. + + + + + + + + + + + + The calibration data and metadata should be described in a separate NeXus file + with the link provided in 'calibration_link'. + + + + If calibtration status is 'calibration time provided', specify the + ISO8601 date when calibration was last performed before this + measurement. UTC offset should be specified. + + + + + Link to the NeXus file containing the calibration data and metadata. + + + + + + Describes an arrangement of optical or other elements, e.g. the beam + path between the light source and the sample, or between the sample + and the detector unit (including the sources and detectors + themselves). + + If a beam splitter (i.e. a device that splits the incoming beam into + two or more beams) is part of the beam path, two or more NXbeam_path + fields may be needed to fully describe the beam paths and the correct + sequence of the beam path elements. + Use as many beam paths as needed to describe the setup. + + + + + Angle(s) of the incident beam vs. the normal of the bottom reflective + (substrate) surface in the sample. + + + + + + + + + Detection angle(s) of the beam reflected or scattered off the sample + vs. the normal of the bottom reflective (substrate) surface in the + sample if not equal to the angle(s) of incidence. + + + + + + + + Sample stage, holding the sample at a specific position in X,Y,Z + (Cartesian) coordinate system and at an orientation defined + by three Euler angles (alpha, beta, gamma). + + + + Specify the type of the sample stage. + + + + + + + + + + + + If there is no motorized stage, we should at least qualify where + the beam hits the sample and in what direction the sample stands + in a free-text description, e.g. 'center of sample, long edge + parallel to the plane of incidence'. + + + + + Specify external parameters that have influenced the sample, such + as the surrounding medium, and varied parameters e.g. temperature, + pressure, pH value, optical excitation etc. + + + + Describe what was the medium above or around the sample. The + common model is built up from the substrate to the medium on the + other side. Both boundaries are assumed infinite in the model. + Here, define the name of the medium (e.g. water, air, UHV, etc.). + + + + + Array of pairs of complex refractive indices n + ik of the medium + for every measured spectral point/wavelength/energy. + Only necessary if the measurement was performed not in air, or + something very well known, e.g. high purity water. + + + + + + + + + A sensor used to monitor an external condition influencing the + sample, such as temperature or pressure. It is suggested to + replace 'PARAMETER' by the type of the varied parameter defined + in 'parameter_type'. + The measured parameter values should be provided in 'values'. + For each parameter, a 'PARAMETER(NXsensor)' field needs to exist. + In other words, there are N_sensors 'PARAMETER(NXsensor)' fields. + + + + Indicates which parameter was changed. Its definition must exist + below. The specified variable has to be N_measurements long, + providing the parameters for each data set. If you vary more than + one parameter simultaneously. + If the measured parameter is not contained in the list `other` + should be specified and the `parameter_type_name` should be provided. + + + + + + + + + + + + + + + + + + + + + + + + + If the parameter_type is `other` a name should be specified here. + + + + + Number of different parameter values at which the measurement + was performed. For example, if the measurement was performed at + temperatures of 4, 77 and 300 K, then number_of_parameters = 3. + + + + + Vector containing the values of the varied parameter. Its + length is equal to N_measurements. The order of the values + should be as follows: + + * Order the sensors according to number_of_parameters starting + with the lowest number. If number_of_parameters is equal for + two sensors order them alphabetically (sensor/parameter name). + * The first sensor's j parameters should be ordered in the + following way. The first N_measurements/number_of_parameters + entries of the vector contain the first parameter (a1), the + second N_measurements/number_of_parameters contain the second + parameter (a2) etc., so the vector looks like: + [ + a1,a1,...,a1, + a2,a2,...,a2, + ... + aj,aj,...aj + ] + * The kth sensor's m parameters should be ordered in the + following way: + [ + p1,...p1,p2,...,p2,...pm,...,pm, + p1,...p1,p2,...,p2,...pm,...,pm, + ... + p1,...p1,p2,...,p2,...pm,...,pm + ] + * The last sensor's n parameters should be ordered in the + following way: + [ + z1,z2,...,zn, + z1,z2,...,zn, + ... + z1,z2,...,zn] + + For example, if the experiment was performed at three different + temperatures (T1, T2, T3), two different pressures (p1, p2) and + two different angles of incidence (a1, a2), then + N_measurements = 12 and the order of the values for the various + parameter vectors is: + + * angle_of_incidence: [a1,a1,a1,a1,a1,a1,a2,a2,a2,a2,a2,a2] + * pressure: [p1,p1,p1,p2,p2,p2,p1,p1,p1,p2,p2,p2] + * temperature: [T1,T2,T3,T1,T2,T3,T1,T2,T3,T1,T2,T3] + + + + + + + + + + For environmental measurements, the environment (liquid, vapor + etc.) is enclosed in a cell, which has windows both in the + direction of the source (entry window) and the detector (exit + window) (looking from the sample). In case that the entry and exit + windows are not the same type and do not have the same properties, + use a second 'WINDOW(MXaperture)' field. + + The windows also add a phase shift to the light altering the + measured signal. This shift has to be corrected based on measuring + a known sample (reference sample) or the actual sample of interest + in the environmental cell. State if a window correction has been + performed in 'window_effects_corrected'. Reference data should be + considered as a separate experiment, and a link to the NeXus file + should be added in reference_data_link in measured_data. + + The window is considered to be a part of the sample stage but also + beam path. Hence, its position within the beam path should be + defined by the 'depends_on' field. + + + + Specify the position of the window in the beam path by pointing + to the preceding element in the sequence of beam path elements. + + + + + Was a window correction performed? If 'True' describe the window + correction procedure in 'window_correction/procedure'. + + + + + Was a window correction performed? If 'True' describe the + window correction procedure in '' + + + + Describe when (before or after the main measurement + time + stamp in 'date') and how the window effects have been + corrected, i.e. either mathematically or by performing a + reference measurement. In the latter case, provide the link to + to the reference data in 'reference_data_link'. + + + + + Link to the NeXus file which describes the reference data if a + reference measurement for window correction was performed. + Ideally, the reference measurement was performed on a reference + sample and on the same sample, and using the same conditions as + for the actual measurement with and without windows. It should + have been conducted as close in time to the actual measurement + as possible. + + + + + + The material of the window. + + + + + + + + + + + + + + + If you specified 'other' as material, decsribe here what it is. + + + + + Thickness of the window. + + + + + Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence). + + + + + + + + Properties of the sample, such as sample type, layer structure, + chemical formula, atom types, its history etc. + Information about the sample stage and sample environment should be + described in ENTRY/INSTRUMENT/sample_stage. + + + + Descriptive name of the sample + + + + + Specify the type of sample, e.g. thin film, single crystal etc. + + + + + + + + + + + + Qualitative description of the layer structure for the sample, + starting with the top layer (i.e. the one on the front surface, on + which the light incident), e.g. native oxide/bulk substrate, or + Si/native oxide/thermal oxide/polymer/peptide. + + + + + Chemical formula of the sample. Use the Hill system (explained here: + https://en.wikipedia.org/wiki/Chemical_formula#Hill_system) to write + the chemical formula. In case the sample consists of several layers, + this should be a list of the chemical formulas of the individual + layers, where the first entry is the chemical formula of the top + layer (the one on the front surface, on which the light incident). + The order must be consistent with layer_structure + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + 'atom_types'. + + + + + Ideally, a reference to the location or a unique (globally + persistent) identifier (e.g.) of e.g. another file which gives + as many as possible details of the material, its microstructure, + and its thermo-chemo-mechanical processing/preparation history. + In the case that such a detailed history of the sample is not + available, use this field as a free-text description to specify + details of the sample and its preparation. + + + + + ISO8601 date with time zone (UTC offset) specified. + + + + + Description of the substrate. + + + + + Specify the sample orientation. + + + + + + Measured data, data errors, and varied parameters. If reference data + were measured they should be considered a separate experiment and a + link to its NeXus file should be added in reference_data_link. + + + + An identifier to correlate data to the experimental conditions, + if several were used in this measurement; typically an index of 0-N. + + + + + Select which type of data was recorded, for example intensity, + reflectivity, transmittance, Psi and Delta etc. + It is possible to have multiple selections. The enumeration list + depends on the type of experiment and may differ for different + application definitions. + + + + + + + + + + + + + + + + + Spectral values (e.g. wavelength or energy) used for the measurement. + An array of 1 or more elements. Length defines N_spectrum. Replace + 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. + + + + + + + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + + + + + + Resulting data from the measurement, described by 'data_type'. + + The first dimension is defined by the number of measurements taken, + (N_measurements). The instructions on how to order the values + contained in the parameter vectors given in the doc string of + INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, + define the N_measurements parameter sets. For example, if the + experiment was performed at three different temperatures + (T1, T2, T3), two different pressures (p1, p2) and two different + angles of incidence (a1, a2), the first measurement was taken at the + parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. + + + + + + + + + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + + + + + + Specified uncertainties (errors) of the data described by 'data_type' + and provided in 'measured_data'. + + + + + + + + + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + + + + + + List of links to the values of the sensors. Add a link for each + varied parameter (i.e. for each sensor). + + + + + + + + Link to the NeXus file which describes the reference data if a + reference measurement was performed. Ideally, the reference + measurement was performed using the same conditions as the actual + measurement and should be as close in time to the actual measurement + as possible. + + + + + + Commercial or otherwise defined given name of the program that was + used to generate the result file(s) with measured data and/or + metadata (in most cases, this is the same as INSTRUMENT/software). + If home written, one can provide the actual steps in the NOTE + subfield here. + + + + + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + + + + Website of the software. + + + + + + A plot of the multi-dimensional data array provided in + ENTRY/data/measured_data. + + + + Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) + + + + + + + Parameters that are derived from the measured data. + + + + Light loss due to depolarization as a value in [0-1]. + + + + + + + + + + Jones quality factor. + + + + + + + + + + Reflectivity. + + + + + + + + + + Transmittance. + + + + + + + + + + + Commercial or otherwise defined given name of the program that was + used to generate or calculate the derived parameters. + If home written, one can provide the actual steps in the NOTE + subfield here. + + + + + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + + + + + + A default view of the data provided in ENTRY/data_collection/measured_data. This + should be the part of the data set which provides the most suitable + representation of the data. + + + + Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) + + + + + diff --git a/contributed_definitions/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/NXorientation_set.nxdl.xml b/contributed_definitions/NXorientation_set.nxdl.xml new file mode 100644 index 000000000..73f5e3ca0 --- /dev/null +++ b/contributed_definitions/NXorientation_set.nxdl.xml @@ -0,0 +1,133 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the reference space/coordinate system. + + + + + The cardinality of the set, i.e. the number of orientations. + + + + + Number of parameters for the chosen parameterization. + + + + + Details about individual orientations of a set of objects. + + For a more detailed insight into the discussion of parameterizing + orientations in materials science see: + + * https://doi.org/10.1016/j.matchar.2016.04.008 + * https://doi.org/10.1088/0965-0393/23/8/083501 + * https://doi.org/10.1007/978-3-662-09156-2 group-theory of rotations + * https://doi.org/10.1016/C2013-0-11769-2 the classical book of H.-J. Bunge + + + + + Reference to or definition of a coordinate system with + which the definitions are interpretable. + + + + + + + + + + + + A link or reference to the objects whose identifier are referred to in + identifier to resolve which row tuple is the orientation of each object + by reading orientations. + + + + + Integer which specifies which orientation (row of array orientation) matches + to which object.e first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish how a row in orientation describes a specific + object with an explicit identifier that can be queried via inspecting the + list of available objects in objects. + + The rational behind having such a more complicated pattern is that not + all objects referred when following the link in objects may still exists + or are still tracked when the orientation set was characterized. + + This design enables to also use NXorientation_set in situations where + the orientation of objects change as a function in time. + + + + + + + + Parameterized orientations. + + + + + + + + + diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml new file mode 100644 index 000000000..4a030c684 --- /dev/null +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -0,0 +1,87 @@ + + + + + + + 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/contributed_definitions/NXpid.nxdl.xml similarity index 70% rename from base_classes/NXpid.nxdl.xml rename to contributed_definitions/NXpid.nxdl.xml index 4941cac93..62fad3f83 100644 --- a/base_classes/NXpid.nxdl.xml +++ b/contributed_definitions/NXpid.nxdl.xml @@ -1,10 +1,10 @@ - + - + Contains the settings of a PID controller. @@ -53,18 +53,12 @@ It can also be a link to an NXsensor.value field. - - - Time log of the setpoint(s) used as an input for the PID controller. - - Proportional term. The proportional term produces an output value that is proportional to the current error value. The proportional response can be adjusted by multiplying the error by a constant Kp, called the proportional gain constant. - The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. @@ -87,25 +81,4 @@ action is termed the derivative gain, K_d - - - The Type switches controller parameters between P/I (proportional gain/integral - gain) and P/T (proportional gain/time constant). The formula for the controller - in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and - time constant are related as follows I = P/T. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - diff --git a/contributed_definitions/NXpositioner_sts.nxdl.xml b/contributed_definitions/NXpositioner_sts.nxdl.xml deleted file mode 100644 index 7d13592b9..000000000 --- a/contributed_definitions/NXpositioner_sts.nxdl.xml +++ /dev/null @@ -1,310 +0,0 @@ - - - - - - A generic positioner such as a motor or piezo-electric transducer. - - - - symbolic or mnemonic name (one word) - - - - - description of positioner - - - - - best known value of positioner - need [n] as may be scanned - - - - - - - - raw value of positioner - need [n] as may be scanned - - - - - - - - targeted (commanded) value of positioner - need [n] as may be scanned - - - - - - - - maximum allowable difference between target_value and value - - - - - - - - minimum allowed limit to set value - - - - - maximum allowed limit to set value - - - - - velocity of the positioner (distance moved per unit time) - - - - - time to ramp the velocity up to full speed - - - - - Hardware device record, e.g. EPICS process variable, taco/tango ... - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a positioner. - - - - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - - - - - To clarify the frame laboratory frame. The scanning area in x, y, and z position in the - frame. - - - - - This controllers task is to continuously adjust the Z position of the stm tip in order - to keep the selected control signal as close as possible to the Set Point. Different control - signals lead to different contronller beahvior. - - - - - Offset added to the initial averaged position Zaver before starting to swepp. - - - - - Indicate the tip position Z between tip and sample. The tip position can also be varied when - the controller is not running. - - - - - Controller name. This name which will be displayed at places where you can select a - controller. - - - - - Set Point is the desired value of the control signal. It can be set by editing the number - or using the slider bar. Click the "Set" button above the input field to use the actual - value as Set Point. The slider shows the Set Point as well as the current value. - - - - - Lifts the tip by the specified amount when then controller is switched off. This can be - a positive or a negative number, i.e. the tip can also be moved towards the sample. Be - careful with sign and value when using this feature. - - - - - Use this parameter for a reproducible position when switching off the Z-controller. - When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues - to run for the specified time and averages the Z position. - - - - - (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during - the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters - are disabled. - - - - - The final z-position during the bias spectroscopy scan. The availability of values is - related to the mode of scanning. - - - - - - Configure the scan frame like x position; y position; width; height. - - - - - Scan resolution by setting the Lines equal to Pixels. - - - - - Define the image resolution. - - - - - Define the scan forward speed in the forward direction. - - - - - Define the scan backward speed in the forward direction. - - - - - Piezo calibration module is used to define the X Y Z piezos calibration. - - - - - The name of caliberation type. - - - - - - - The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and :math:`P/T` - (proportional gain/time constant). The formula for the controller in the frequency domain is: - :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. - The integral gain and time constant are related as follows: :math:`I = P/T`. - - - - - The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and - P/T (proportional gain/time constant). The formula for the controller in the frequency - domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related - as follows: `:math:I = P/T`. - - - - - The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and - :math:`P/T` (proportional gain/time constant). The formula for the controller in the frequency - domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related - as follows: :math:`I = P/T`. - - - - - - There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order - piezo characteristics to compensate for it. The following equation shows the interpretation - of the 2nd order correction parameter: For the X-piezo: - :math:`Ux = 1/cx · X + cxx · X2`; with units: :math:`[V] = [V/m] · [m] + [V/m2] · [m2]` - where cx is the calibration of the piezo X and cxx is the 2nd order correction. :math:`(V/m^2)` - - - - - There are 2 parameters in X and Y directions. Define the drift speed for all three axes. - When the compensation is on, the piezos will start to move at that speed. - - - - - Use the button to turn on/off the drift compensation. - - - diff --git a/base_classes/NXprogram.nxdl.xml b/contributed_definitions/NXprogram.nxdl.xml similarity index 100% rename from base_classes/NXprogram.nxdl.xml rename to contributed_definitions/NXprogram.nxdl.xml 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/base_classes/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml similarity index 88% rename from base_classes/NXpump.nxdl.xml rename to contributed_definitions/NXpump.nxdl.xml index 45a86edad..9f38b2d7b 100644 --- a/base_classes/NXpump.nxdl.xml +++ b/contributed_definitions/NXpump.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Device to reduce an atmosphere (real or simulated) to a controlled pressure. + Device to reduce an atmosphere to a controlled remaining pressure level. - + Principle type of the pump. diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml 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/base_classes/NXregistration.nxdl.xml b/contributed_definitions/NXregistration.nxdl.xml similarity index 100% rename from base_classes/NXregistration.nxdl.xml rename to contributed_definitions/NXregistration.nxdl.xml diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml new file mode 100644 index 000000000..c95f62357 --- /dev/null +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + 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/NXsensor_scan.nxdl.xml b/contributed_definitions/NXsensor_scan.nxdl.xml index bea9efa21..be67c3c15 100644 --- a/contributed_definitions/NXsensor_scan.nxdl.xml +++ b/contributed_definitions/NXsensor_scan.nxdl.xml @@ -1,10 +1,10 @@ - + - + Variables used to set a common size for collected sensor data. @@ -45,7 +45,7 @@ - + @@ -123,7 +123,7 @@ NXsensor groups. Similarly, seperate NXsensor groups are used to store the readings from each measurement sensor. - For example, in a temperature-dependent IV measurement, the temperature and voltage must be + For example, in a temperature-dependent IV measurement, the temperature and voltage must be present as independently scanned controllers and the current sensor must also be present with its readings. diff --git a/contributed_definitions/NXsensor_sts.nxdl.xml b/contributed_definitions/NXsensor_sts.nxdl.xml deleted file mode 100644 index 31094bd4e..000000000 --- a/contributed_definitions/NXsensor_sts.nxdl.xml +++ /dev/null @@ -1,233 +0,0 @@ - - - - - - A sensor used to monitor an external condition - - The condition itself is described in :ref:`NXenvironment`. - - - - Sensor identification code/model number - - - - - Name for the sensor - - - - - Short name of sensor used e.g. on monitor display program - - - - - where sensor is attached to ("sample" | "can") - - - - - Defines the axes for logged vector quantities if they are not the global - instrument axes. - - - - - name for measured signal - - - - - - - - - - - - - - - - - - - - - The type of hardware used for the measurement. - Examples (suggestions but not restrictions): - - :Temperature: - J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe - :pH: - Hg/Hg2Cl2 | Ag/AgCl | ISFET - :Ion selective electrode: - specify species; e.g. Ca2+ - :Magnetic field: - Hall - :Surface pressure: - wilhelmy plate - - - - - - link to second amplifer circuit with 1MOhm - - - - - Is data collection controlled or synchronised to this quantity: - 1=no, 0=to "value", 1=to "value_deriv1", etc. - - - - - Upper control bound of sensor reading if using run_control - - - - - Lower control bound of sensor reading if using run_control - - - - - nominal setpoint or average value - - need [n] as may be a vector - - - - - - - - Nominal/average first derivative of value - e.g. strain rate - - same dimensions as "value" (may be a vector) - - - - - - - - Nominal/average second derivative of value - - same dimensions as "value" (may be a vector) - - - - - - - - Time history of sensor readings - - - - - Time history of first derivative of sensor readings - - - - - Time history of second derivative of sensor readings - - - - - - - - - - - - - - - For complex external fields not satisfied by External_field_brief - - - - - This group describes the shape of the sensor when necessary. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a sensor. - - - - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - - - - - External sensors connected to the device. For example, T1, temperature of STM - head. T2, temperature of bottom of LHe helium cryostat. T3, temperature of LN2 - nitrogen shield. - - - - - External sensors connected to the device. Pressure of each chamber or ion pump, - such as prepare chamber and analysis chamber - - - - - The power present in the signal as a function of frequency. Used to characterise - the vibration and noise of scanning probes to detect and reduce the impact on - resolution during STM imaging - - - 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/NXmicrostructure_slip_system.nxdl.xml b/contributed_definitions/NXslip_system_set.nxdl.xml similarity index 79% rename from contributed_definitions/NXmicrostructure_slip_system.nxdl.xml rename to contributed_definitions/NXslip_system_set.nxdl.xml index ec660d6de..8fafee2e4 100644 --- a/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml +++ b/contributed_definitions/NXslip_system_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -35,10 +35,11 @@ Base class for describing a set of crystallographic slip systems. - - - Bravais lattice type - + + + @@ -49,16 +50,19 @@ + - Array of Miller indices which describe the crystallographic planes. + Array of Miller indices which describe the crystallographic plane. - + Array of Miller indices which describe the crystallographic direction. @@ -70,8 +74,9 @@ - For each slip system a marker whether the specified Miller indices refer to - a specific or a crystallographic equivalent set of the slip system. + For each slip system a marker whether the specified Miller indices + refer to the specific slip system or the set of crystallographic equivalent + slip systems of the respective family of slip systems. diff --git a/contributed_definitions/NXspatial_filter.nxdl.xml b/contributed_definitions/NXspatial_filter.nxdl.xml index 7103ab86b..25e5ae820 100644 --- a/contributed_definitions/NXspatial_filter.nxdl.xml +++ b/contributed_definitions/NXspatial_filter.nxdl.xml @@ -1,10 +1,10 @@ - + - - + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + Number of ellipsoids. + + Number of hexahedra. @@ -39,51 +44,42 @@ n_facets: Number of facets for polyhedra.--> Number of cylinders. - - - Number of ellipsoids. - - - - - Number of polyhedra. - - - Base class for a spatial filter for objects within a region-of-interest (ROI). - - Objects can be points or objects composed from other geometric primitives. + Spatial filter to filter entries within a region-of-interest based on their + position. - + - Qualitative statement which describes the logical operations - that define which objects will be included and which excluded: + Qualitative statement which specifies which spatial filtering with respective + geometric primitives or bitmask is used. These settings are possible: - * entire_dataset, no filter is applied, all objects are included. - * union_of_primitives, a filter with (possibly non-axis-aligned) geometric - primitives. Objects in or on the surface of the primitives are included. - All other objects are excluded. - * bitmask, a boolean array whose bits encode with 1 which objects - are included. Bits set to zero encode which objects are excluded. - Users of python can use the bitfield operations - of the numpy package to work with bitfields. + * entire_dataset, no filter is applied, the entire dataset is used. + * union_of_primitives, a filter with (rotated) geometric primitives. + All ions in or on the surface of the primitives are considered + while all other ions are ignored. + * bitmasked_points, a boolean array whose bits encode with 1 + which ions should be included. Those ions whose bit is set to 0 + will be excluded. Users of python can use the bitfield operations + of the numpy package to define such bitfields. + + Conditions: + In the case that windowing_method is entire_dataset all entries are processed. + In the case that windowing_method is union_of_primitives, + it is possible to specify none or all types of primitives + (ellipsoids, cylinder, hexahedra). If no primitives are specified + the filter falls back to entire_dataset. + In the case that windowing_method is bitmask, the bitmask has to be defined; + otherwise the filter falls back to entire dataset. - - - - + + diff --git a/contributed_definitions/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/NXspectrum_set_em_eels.nxdl.xml b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml new file mode 100644 index 000000000..4e58d9202 --- /dev/null +++ b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml @@ -0,0 +1,188 @@ + + + + + + + + + Number of pixel per EELS mapping in the slow direction. + + + + + Number of pixel per EELS mapping in the fast direction. + + + + + Number of electron energy loss bins. + + + + + Container for reporting a set of electron energy loss (EELS) spectra. + + Virtually the most important case is that spectra are collected in + a scanning microscope (SEM or STEM) for a collection of points. + The majority of cases use simple d-dimensional regular scan pattern, + such as single point, line profiles, or (rectangular) surface mappings. + + The latter pattern is the most frequently used. + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. + + + + Details how EELS spectra were processed from the detector readings. + + + + Typically the name of the input, (vendor) file from which all + the NXdata instances in this NXspectrum_set_em_eels were loaded during + parsing to represent them in e.g. databases. + + + + An at least as strong as SHA256 hashvalue of the dataset/file + which represents the source digitally to support provenance tracking. + + + + + + Commercial or otherwise given name to the program which was used + to process detector data into the EELS spectra stack and summary. + + + + Program version plus build number, commit hash, or description + of an ever persistent resource where the source code of the program + and build instructions can be found so that the program + can be configured in such a manner that the result file + is ideally recreatable yielding the same results. + + + + + + + Collected EELS spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + Counts for one spectrum per each pixel. + + + + + + + + + EELS counts + + + + + + + Pixel center of mass position y-coordinates. + + + + + + + Coordinate along y direction. + + + + + + Pixel center of mass position x-coordinates. + + + + + + + Coordinate along x direction. + + + + + + Pixel center of mass energy loss bins. + + + + + + + Coordinate along energy loss axis. + + + + + + + Accumulated EELS spectrum over all pixels of a rectangular + region-of-interest. This representation supports rectangular scan pattern. + + + + Counts for specific energy losses. + + + + + + + Counts electrons with an energy loss within binned range. + + + + + + + Pixel center of mass energy loss bins. + + + + + + + Coordinate along energy loss axis. + + + + + diff --git a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml new file mode 100644 index 000000000..53916bbfe --- /dev/null +++ b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml @@ -0,0 +1,311 @@ + + + + + + + + + + Number of pixel per X-ray mapping in the slow direction + + + + + Number of pixel per X-ray mapping in the fast direction + + + + + Number of X-ray photon energy (bins) + + + + + Number of identified elements + + + + + Number of peaks + + + + + Container for reporting a set of energy-dispersive X-ray spectra. + + Virtually the most important case is that spectra are collected in + a scanning microscope (SEM or STEM) for a collection of points. + The majority of cases use simple d-dimensional regular scan pattern, + such as single point, line profiles, or (rectangular) surface mappings. + The latter pattern is the most frequently used. + + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ + should be used. + + + + Details how X-ray spectra were processed from the detector readings. + + + + Typically the name of the input, (vendor) file from which all + the NXdata instances in this NXspectrum_set_em_xray were loaded during + parsing to represent them in e.g. databases. + + + + An at least as strong as SHA256 hashvalue of the dataset/file + which represents the source digitally to support provenance tracking. + + + + + + Commercial or otherwise given name to the program which was used + to process detector data into the X-ray spectra stack and summary. + + + + Program version plus build number, commit hash, or description + of an ever persistent resource where the source code of the program + and build instructions can be found so that the program + can be configured in such a manner that the result file + is ideally recreatable yielding the same results. + + + + + + + + Collected X-ray spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + X-ray photon counts + + + + + + + + + + + Coordinate along y direction. + + + + + + + + + + Coordinate along x direction. + + + + + + + + + + Photon energy. + + + + + + + Accumulated X-ray spectrum over all pixels of a rectangular + region-of-interest. This representation supports rectangular scan pattern. + + + + + + + + X-ray photon counts + + + + + + + + + + + Photon energy + + + + + + + + Details about computational steps how peaks were indexed as elements. + + + + Given name of the program that was used to perform this computation. + + + + Program version plus build number, commit hash, or description of an + ever persistent resource where the source code of the program and + build instructions can be found so that the program can be configured + in such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are group with the same peak. + + + + + + + List of the names of identified elements. + + + + + + + + Individual element-specific EDX/EDS/EDXS/SXES mapping + + A composition map is an image whose intensities for each pixel are the + accumulated X-ray quanta *under the curve(s)* of a set of peaks. + + + + Given name of the program that was used to perform this computation. + + + + Program version plus build number, commit hash, or description of an + ever persistent resource where the source code of the program and + build instructions can be found so that the program can be configured + in such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + A list of strings of named instances of NXpeak from indexing + whose X-ray quanta where accumulated for each pixel. + + + + + + + + Human-readable, given name to the image. + + + + + + Individual element-specific maps. Individual maps should + each be a group and be named according to element_names. + + + + + + + + + Accumulated photon counts for observed element. + + + + + + + + + + + Coordinate along y direction. + + + + + + + + + + Coordinate along x direction. + + + + + + + diff --git a/base_classes/NXspindispersion.nxdl.xml b/contributed_definitions/NXspindispersion.nxdl.xml similarity index 100% rename from base_classes/NXspindispersion.nxdl.xml rename to contributed_definitions/NXspindispersion.nxdl.xml diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 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. + + + + + diff --git a/contributed_definitions/NXsts.nxdl.xml b/contributed_definitions/NXsts.nxdl.xml deleted file mode 100644 index f13d5a90c..000000000 --- a/contributed_definitions/NXsts.nxdl.xml +++ /dev/null @@ -1,995 +0,0 @@ - - - - - - - - - - Application definition for temperature-dependent IV curve measurements - #2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the - STM image mode in the future with a focus on bias spectroscopy in Scanning Tunneling Microscopy. - - In this application definition, times should be specified always together with a UTC offset. - - This is the application definition describing temperature (T) dependent current voltage (IV) curve - measurements. For this, a temperature is set. After reaching the temperature, a voltage sweep - is performed. For each voltage, a current is measured. - Then, the next desired temperature is set and an IV measurement is performed. - The data can be visualized in a tensor with: - I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) - parameters: - V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) - T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) - x has (NXsoftware_Scan_offset) - y has (NXsoftware_Scan_offset) - z has (NXsoftware_Scan_offset) - - - - - - - - - - Name of the experiment where the application is applicable. - - - - - - - - - The equipments and techniques as well as the parameter settings and reference signals - are used during the experiments used in Scanning Tunneling Microscopy (STM). - - - - - - - - - - - The name of the output file, with the number of scans at the end. (e.g. - 221122_Au_5K00014) - - - - - The name of the series output file, which represents only the public part of the - output file. (e.g. 221122_Au_5K) - - - - - Path to storage of output files. - (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) - - - - - Descriptive comments for this experiment, added by the experimenter, coming from the - output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), - 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) - - - - - - Hardware type used in SPM experiment, includes hardware manufacturers and type. - (e.g. Nanonis BP5e) - - - - - - Type of software used in SPM experiments, such as software version serial number, UI and - RT probe release method. (e.g. SW Version Generic 5e -- RT Release 10771) - - - - - - The Amplifier description that improves or helps to determine tunnel current (current - between tip and bias). - - - - - - - Status of Lock-in device whether while performing the experiment - - - - - - This is the signal on which the modulation (sine) will be added. - - - - - - - The signal is modulated by adding the frequency of the sine modulation. The - modulation frequency spans can be from 10 mHz to 40 kHz, corresponding to the output filter - cut-off range. When dealing with harmonics, it's essential to ensure that the - harmonic frequencies remain below ~100 kHz, which aligns with the input filter cut-off. - Be mindful that hardware filters might impact the amplitude as the signal approaches - their cut-off frequencies." (e.g. 973E+0) - - - - - - The amplitude (in physical units of modulated signal) of the sine modulation. - - - - - - The input signal (STS signal) will be demodulated, in order to determine the amplitude - and phase at the frequency set in the Frequency field or harmonics, such as current, - bias, et.al. - - - - - - N denotes 1 or 2. The order of the harmonic oscillation to be detected in the demodulated - signal should be considered relative to the modulation frequency. When dealing with - higher harmonics, it's essential to ensure that their frequencies do not surpass - the analogue signal bandwidth (e.g. harmonic_order_1). - - - - - - Reference phase for the sine on the demodulated signal with respect to the - modulation signal. The determined phase is displayed with respect to the - reference phase. - - - - - - - - Bias voltage applied to the sample. - - - - Applied a voltage between tip and sample. - - - - - - - - - Temperature of STM head. Note: At least one field from stm_head_temperature, - cryo_bottom_temp and cryo_sheild_temp must be provided. - - - - - Temperature of liquid helium cryostat. Note: At least one field from - stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. - - - - - Temperature of liquid nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At - least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp - must be provided. - - - - - - - Configuration for piezoelectric scanner used to move tip along X and Y direction. The - material of the Piezoelectric scanner composed of polycrystalline solids and sensitive to - applied voltage. - - - - The name of calibration type. (e.g. LHe) - - - - - N denotes X or Y or Z. There are three parameters in the X, Y, and Z directions, - along with three available controls: Calibration (m/V), Range (m), and HV gain. Only - two of these parameters are required to define the calibration. Consequently, when any - value is changed, one of the other values will be automatically updated. (e.g. calib_X = 3.8E-9) - - - - - N denotes X or Y or Z. In some systems, there is an HV gain readout feature. For - these systems, the HV gain should be automatically adjusted whenever the gain is - changed at the high voltage amplifier. (e.g. 14.5) - - - - - - N denotes X or Y. There are 2 parameters in X and Y directions, and tilt needs to be - adjusted according to the actual surface. (in degrees, first order correction). - - - - - - N denotes X or Y. There are 2 parameters in X and Y directions. (can be set - approximately to the length of the piezotube). - - - - - N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, - you can enter the 2nd order piezo characteristics to compensate for it. The - following equation shows the interpretation of the 2nd order correction parameter: - For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: - [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx - is the 2nd order correction. (V/m^2). (e.g. 0E+0) - - - - - N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the - drift speed for all three axes. When the compensation is on, the piezos will start to - move at that speed. (e.g. 0E+0) - - - - - Use the button to enable or disable the drift compensation. (e.g. FALSE) - - - - - - An environmental setup to measure the tunneling current due to different tip- - sample biases. - - - - - This is set-point of tip current (in the constant current mode should be equal to set-point, - in the constant height mode means the real tunnelling current between tip and sample). - - - - - Value of calibration that comes as A/V. The value for this concept can be read - as current per unit voltage. - - - - - - - - - - Clarify the frame laboratory frame. - - - - The scanning area in x position in the frame. (e.g. -890.53E-12) - - - - - The scanning area in y position in the frame. (e.g. 29.6968E-9) - - - - - The scanning area in z position in the frame. (e.g. 130.5E-9) - - - - - - Indicate the relative tip position z between tip and sample. The tip position can also - be varied when the z_controller is not running. (e.g. 130.5E-9) - - - - - - - - - - Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) - - - - - Number of sweeps to measure and average. (e.g. 100) - - - - - The start bias values of the sweep. (e.g. -300E-3) - - - - - The end bias values of the sweep. (e.g. 300E-3) - - - - - The sweep number of points is defined as the maximum spectrum resolution, which - is equal to the bias sweep window divided by the number of pixels. (e.g. 4096) - - - - - The Z position is recorded and averaged for a certain duration both before and - after the sweep. After the initial Z averaging time, if "Z-Controller to Hold" - is selected, the Z-Controller is set to hold mode, and the tip is positioned at - the previously averaged Z position (adjusted by the Z offset). (e.g. 100E-3) - - - - - - - The bandwidth of the Hardware and/or Software is instrument specific. - For example, Nanonis Generic 5 has 'RT Frequency' (e.g. 20E+3). - - - - - The Signals Period represents the rate at which signals are transferred to - the host computer, which operates the control software. This rate may - be 10 times lower than the sampling rate, as the real-time engine internally - oversamples the signal. If desired, you may have the option to reduce the oversampling - to 1, enabling higher frequency resolution in the Spectrum Analyzer. (e.g. 10) - - - - - The update rate is utilized in various processes, including the History Graph, - Auto-Approach, and multiple Programming Interface functions. It may be - configured to a 20 ms interval. Any additional timings must strictly be integer - multiples of this base value. While it is possible to set these additional - timings to different values, the actual timing value will automatically be - adjusted to become a multiple of the Acquisition Period. (e.g. 20E-3) - - - - - The update rate of animated graphical indicators, such as graphs and sliders, - can be adjusted. A normal value may be 40 ms, which corresponds to 25 updates - per second. Increasing this period can help reduce the processor load on the - graphical user interface, particularly on slower computers. It is important to - note that this update rate solely impacts the user interface and does not affect - measurements in any manner. (e.g. 20E-3) - - - - - The update rate of digital indicators, such as the numbers displayed, can be set - to 3 updates per second, equivalent to 300 ms. This interval is sufficient for - the user interface and does not impact measurements in any manner. (e.g. 300E-3) - - - - - The Measurements period determines the integration time required for precise - measurements, primarily utilized in sweep modules. It is particularly useful for - tasks such as recording force-distance curves or cantilever resonances. For - swift measurements with small steps, a value of 40 ms is often adequate. For - regular use, a range of 300-500 ms may be recommended, but when capturing the - resonance of a high-Q cantilever, longer values in the range of several seconds - might be necessary. Usually, this parameter does not require manual adjustment - within this module, as the sweep modules automatically set this value according - to the sweep timings. (e.g. 500E-3) - - - - - - - - - In STM experiment, the scan range is the coordinate (x,y) along the X and Y axis from the origin (scan_offset) of - the scan area (e.g. 5.000000E-9 5.000000E-9). - - - - - In STM experiment, the scan offset is the position of the tip at the starting point of scan area. - (e.g. -2.354637E-7 1.267476E-) - - - - - In STM experiment, the scan direction is the direction from which side of the - sample the tip starts scanning. - - - - - - - - - - - The angle of scan with the bottom or top side (depends on the scan_direction - field) of the sample. (e.g. 0.000E+0). - - - - - - Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab - frame is (0, 0), and positive in x means right and in y means up. - - - - - - - The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X - (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) - - - - - - - Configure the scan frame like x position; y position; width; height. (e.g. - 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0). If the 'scanfield' is not considered, use - the 'scan_range' and 'scan_offset' from 'scan_control' group - - - - - Scan resolution by setting the Lines equal to Pixels. (e.g. 512) - - - - - Define the image resolution. (e.g. 512) - - - - - Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - - - - - Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - - - - - - - - - - - - Link to target: /NXentry/NXinstrument/stm_head_temp - - - - - - Link to target: /NXentry/NXinstrument/cryo_bottom_temp - - - - - - Link to target: /NXentry/NXinstrument/temp_cryo_shield - - - - - - Link to target: /NXentry/NXinstrument/NXlock_in/modulation_signal - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/NXintegration_time - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/number_of_sweeps - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_start - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_end - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/num_pixel - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_avg_time - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/rt_frequency - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/signals_oversampling - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/acquisition_period - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/animations_period - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/indicators_period - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/measurements_period - - - - - - - - - Link to target: /NXentry/NXinstrument/NXsample_bias/bias - - - - - - Link to target: /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current - - - - - - Link to target: /NXentry/NXnstrument/NXsample_bias/bias_calibration - - - - - Link to target: /NXentry/NXinstrument/NXsample_bias/bias_offset - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_calibration - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_offset - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_gain - - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_offset - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/settling_time - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_ccontroller_hold - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/record_final_z - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/first_settling_time - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/end_settling_time - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_control_time - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/max_slew_rate - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/backward_sweep - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_name - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_status - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/set_point - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/p_gain - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/i_gain - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/time_const - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/tip_lift - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/switchoff_delay - - - - - - This describes the sample and its properties, as well as constraints that are - applied to the sample before scanning. - - - - At this moment no base class available that can track entire sample preparation. - - - - - - - This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. - There should also be two more fields called temperature and voltage containing the setpoint values. - There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension - equal to the number of voltage setpoints. - axes: bias_calc - signals: - li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] - current_[-;bwd;filt;bwd_filt] - temperature - - - - - - Plot for a single point (x,y) with I vs. V curve. - - - - - - Line scan with multiple I vs. V curves for different single (x,y) co-ordinates. - - - - - - Plot for current(I) curve in the 2D space of (position(x), bias(V)) which can be - derived from the `line_scan` plot. - - - - - - Mesh scan with 2D slices of the above alternative plot for other y co-ordinates. - - - - diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 2ecb9877a..ea378eab3 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -1,4 +1,4 @@ - + - - + + + + 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/NXtransmission.nxdl.xml b/contributed_definitions/NXtransmission.nxdl.xml index 15ed29e3b..1fb2d51d4 100644 --- a/contributed_definitions/NXtransmission.nxdl.xml +++ b/contributed_definitions/NXtransmission.nxdl.xml @@ -1,10 +1,10 @@ - + - - + Variables used throughout the experiment @@ -72,7 +71,7 @@ Draft NeXus application definition for transmission experiments--> Start time of the experiment. - + Unique identifier of the experiment, such as a (globally persistent) unique identifier. @@ -81,7 +80,7 @@ Draft NeXus application definition for transmission experiments--> investigator. * The identifier enables to link experiments to e.g. proposals. - + An optional free-text description of the experiment. However, details of the @@ -100,12 +99,12 @@ of instrument.--> used to generate the result file(s) with measured data and metadata. - + Version number of the program that was used to generate the result file(s) with measured data and metadata. - + Website of the software @@ -334,10 +333,8 @@ of instrument.--> - + Properties of the sample measured diff --git a/base_classes/NXwaveplate.nxdl.xml b/contributed_definitions/NXwaveplate.nxdl.xml similarity index 95% rename from base_classes/NXwaveplate.nxdl.xml rename to contributed_definitions/NXwaveplate.nxdl.xml index 02178ac9f..52abcb0ba 100644 --- a/base_classes/NXwaveplate.nxdl.xml +++ b/contributed_definitions/NXwaveplate.nxdl.xml @@ -1,4 +1,4 @@ - + - - + + @@ -84,11 +83,6 @@ A draft of a new base class to describe a waveplate--> - - - Wavelength resolved retardence of the waveplate. - - Diameter of the waveplate. diff --git a/contributed_definitions/NXxrd.nxdl.xml b/contributed_definitions/NXxrd.nxdl.xml deleted file mode 100644 index c534d8194..000000000 --- a/contributed_definitions/NXxrd.nxdl.xml +++ /dev/null @@ -1,99 +0,0 @@ - - - - - - - NXxrd on top of NXmonopd - - - - - Official NeXus NXDL schema to which this file conforms - - - - - - - - - - - - - raw detector signal (usually counts) as colected - it can be a multi-dimensional dataset depending on - the detector type (faster axes) and - the scanning method (slower axes) - - - - - The 2-theta range of the difractogram - - - - - - - - - - - - - - - - link (suggested target:/NXentry/NXinstrument/NXdetector/polar_angle) - Link to ponglar ale in /NXentry/NXinstrument/NXdetector - - - - - - - - link (suggested target:/NXentry/NXinstrument/NXdetector/data) - Link to data in /Nxentry/Nxinstrument/Nxdetector - - - - - - - - - Description of a processing or analysis step, such as the - baseline extraction or azimuth integration. - Add additional fields as needed to describe value(s) of - any variable, parameter, or term related to - the NXprocess step. Be sure to include units attributes - for all numerical fields. - - - - diff --git a/contributed_definitions/NXxrd_pan.nxdl.xml b/contributed_definitions/NXxrd_pan.nxdl.xml deleted file mode 100644 index 4918e4ef4..000000000 --- a/contributed_definitions/NXxrd_pan.nxdl.xml +++ /dev/null @@ -1,335 +0,0 @@ - - - - - - NXxrd_pan is a specialisation of NXxrd with extra properties - for the PANalytical XRD data format. - - - - - Name of the data file. - - - - - Type of measurement. - - - - - Official NeXus NXDL schema to which this file conforms. - - - - - - - - Method used to collect the data - default='X-Ray Diffraction (XRD)' - - - - - - - - - - - Type of the X-ray tube. - - - - - - - - - - - - - - Current of the X-ray tube. - - - - - Voltage of the X-ray tube. - - - - - - Wavelength of the K\u03b1 1 line. - - - - - - - - - - Wavelength of the K\u03b1 2 line. - - - - - - - - - - K\u03b1 2/K\u03b1 1 intensity ratio. - - - - - Wavelength of the K\u00df line. - - - - - - - - - - Wavelength of the X-ray source. Used to convert from 2-theta to Q. - - - - - - - Axis scanned. - - - - - Mode of scan. - - - - - Integration time per channel. - - - - - - - - Collect user inputs e.g. name or path of the input file. - - - - - Starting value of the diffraction angle. - - - - - Ending value of the diffraction angle. - - - - - Minimum step size in-between two diffraction angles. - - - - - - - Starting value of the incident angle. - - - - - Ending value of the incident angle. - - - - - Minimum step size in the between two incident angles. - - - - - - Beam attenuation factors over the path. - - - - - Goniometer position X. - - - - - Goniometer position Y. - - - - - Goniometer position Z - - - - - Total time of count. - - - - - - All experiment results data such as scattering angle (2theta), - intensity, incident angle, scattering vector, etc will be stored here. - - - - Number of scattered electrons per unit time. - - - - - - - - Two-theta (scattering angle) of the diffractogram. - - - - - - - - Incident angle of the diffractogram. - - - - - - - - The phi range of the diffractogram. - - - - - - - - The chi range of the diffractogram - - - - - - - - The scattering vector component, which is parallel to the sample surface. - - - - - The scattering vector component, which is perpendicular to the sample surface. - - - - - The norm value of the scattering vector, q. The scattering vector is defined as a - difference between the incident and scattered wave vectors. - For details: https://en.wikipedia.org/wiki/Powder_diffraction - and https://theory.labster.com/scattering-vector/ - - - - - - The desired view for scattering vectors. - - - - This concept corresponds to the norm value of the scattering vector(q). - The concept is the same as 'q_norm' of 'experiment_result' - and should be linked to /entry[ENTRY]/experiment_result/q_norm. - - - - - Number of scattered electrons per unit time at each scattering vector (q) value. - The concept is the same as the 'intensity' of experiment_result - and should be linked to /entry[ENTRY]/experiment_result/intensity. - - - - - The scattering vector (q) component, which is parallel to the sample surface. - This component is used in the Reciprocal Space Mapping (RSM) technique of - X-ray diffraction method. - - The concept is the same as 'q_parallel' of experiment_result, - and should be linked to /entry[ENTRY]/experiment_result/q_parallel. - - - - - The scattering vector component, which is perpendicular to the sample surface. - - The concept is the same as 'q_perpendicular' of experiment_result, - and should be linked to /entry[ENTRY]/experiment_result/q_perpendicular. - - - - - - Description on sample. - - - - Mode of sample. - - - - - Id of sample. - - - - - Usually in xrd sample are being analysed, but sample might be identified by - assumed name or given name. - - - - - diff --git a/dev_tools/docs/anchor_list.py b/dev_tools/docs/anchor_list.py index 1b411041d..df668ead0 100644 --- a/dev_tools/docs/anchor_list.py +++ b/dev_tools/docs/anchor_list.py @@ -114,10 +114,6 @@ def write(self): return contents = dict( _metadata=dict( - # datetime=datetime.datetime.now(datetime.UTC).isoformat(), - # the next line is the py3.9 supported way of getting the datetime - # this will become deprecated however in py3.12 for which the - # line above-mentioned is a fix, which however does not work in py3.9 datetime=datetime.datetime.utcnow().isoformat(), title="NeXus NXDL vocabulary.", subtitle="Anchors for all NeXus fields, groups, " diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py old mode 100755 new mode 100644 index ed3db94cc..157acce33 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -303,34 +303,12 @@ def _get_doc_blocks(ns, node): out_blocks.append("\n".join(out_lines)) return out_blocks - def _handle_multiline_docstring(self, blocks): - links = [] - docstring = "" - expanded_blocks = [] - for block in blocks: - expanded_blocks += block.split("\n") - - for block in expanded_blocks: - if not block: - continue - - link_match = re.search(r"\.\. _([^:]+):(.*)", block) - if link_match is not None: - links.append((link_match.group(1), link_match.group(2).strip())) - else: - docstring += " " + re.sub(r"\n", " ", block.strip()) - - for name, target in links: - docstring = docstring.replace(f"`{name}`_", f"`{name} <{target}>`_") - - return docstring - def _get_doc_line(self, ns, node): blocks = self._get_doc_blocks(ns, node) if len(blocks) == 0: return "" if len(blocks) > 1: - return self._handle_multiline_docstring(blocks) + raise Exception(f"Unexpected multi-paragraph doc [{'|'.join(blocks)}]") return re.sub(r"\n", " ", blocks[0]) def _get_minOccurs(self, node): diff --git a/dev_tools/docs/nxdl_index.py b/dev_tools/docs/nxdl_index.py index 9f0fc779f..bcb8ac666 100644 --- a/dev_tools/docs/nxdl_index.py +++ b/dev_tools/docs/nxdl_index.py @@ -66,22 +66,13 @@ def nxdl_indices() -> Dict[str, dict]: else: file = "" print("---------++++++++-", section) - if file.endswith(("applications/index.rst", "base_classes/index.rst")): - rst_lines.append(f"{indentation}em-structure\n") - rst_lines.append(f"{indentation}optical-spectroscopy-structure\n") - rst_lines.append(f"{indentation}mpes-structure\n") - rst_lines.append(f"{indentation}apm-structure\n") - if file.endswith("contributed_definitions/index.rst"): rst_lines.append(f"{indentation}em-structure\n") - rst_lines.append(f"{indentation}optical-spectroscopy-structure\n") + rst_lines.append(f"{indentation}ellipsometry-structure\n") rst_lines.append(f"{indentation}mpes-structure\n") rst_lines.append(f"{indentation}apm-structure\n") rst_lines.append(f"{indentation}transport-structure\n") - rst_lines.append(f"{indentation}sts-structure\n") rst_lines.append(f"{indentation}cgms-structure\n") - rst_lines.append(f"{indentation}icme-structure\n") - rst_lines.append(f"{indentation}sample-prep-structure\n") for cname in sorted(classes): rst_lines.append(f"{indentation}{cname}\n") @@ -119,18 +110,6 @@ def get_nxclass_description(nxdl_file: Path, namespaces) -> str: *might* be used in an instance of that class. Consider the base classes as a set of *components* that are used to construct a data file. - -Some contributions are grouped together: - :ref:`Optical Spectroscopy ` - - :ref:`Multi-dimensional Photoemission Spectroscopy ` - - :ref:`Atomprobe Microscopy ` - - :ref:`Electron Microscopy ` - -and others are simply listed here: - """, # - - - - - - - - - - - - - - - - - - - - - - - - - - - - "applications": """ @@ -159,19 +138,6 @@ def get_nxclass_description(nxdl_file: Path, namespaces) -> str: In application definitions involving raw data, write the raw data in the :ref:`NXinstrument` tree and then link to it from the location(s) defined in the relevant application definition. - -Some contributions are grouped together: - :ref:`Optical Spectroscopy ` - - :ref:`Multi-dimensional Photoemission Spectroscopy ` - - :ref:`Atomprobe Microscopy ` - - :ref:`Electron Microscopy ` - - -and others are simply listed here: - """, # - - - - - - - - - - - - - - - - - - - - - - - - - - - - "contributed_definitions": """ @@ -194,11 +160,11 @@ def get_nxclass_description(nxdl_file: Path, namespaces) -> str: and acceptance as either a base class or application definition. Some contributions are grouped together: - :ref:`Optical Spectroscopy ` + :ref:`Optical Spectroscopy ` :ref:`Multi-dimensional Photoemission Spectroscopy ` - :ref:`Atomprobe Microscopy ` + :ref:`Atom Probe Microscopy ` :ref:`Electron Microscopy ` diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index ba6b14f25..7b10494bf 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -5,7 +5,6 @@ import os import lxml.etree as ET -import pytest from ..utils import nxdl_utils as nexus @@ -49,175 +48,11 @@ def test_get_node_at_nxdl_path(): ) assert node.attrib["name"] == "long_name" - nxdl_file_path = os.path.join(local_dir, "../../applications/NXem.nxdl.xml") - elem = ET.parse(nxdl_file_path).getroot() - node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/end_time", elem=elem - ) - assert node.attrib["name"] == "end_time" - - node = nexus.get_node_at_nxdl_path("/ENTRY/measurement", elem=elem) - assert node.attrib["type"] == "NXem_msr" - - node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_SET/image_3d", - elem=elem, - ) - assert node.attrib["type"] == "NXdata" - - node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_SET/image_3d/AXISNAME_indices", - elem=elem, - ) - assert node.attrib["name"] == "AXISNAME_indices" - - node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_SET/image_3d/axis_j", - elem=elem, - ) - assert node.attrib["type"] == "NX_NUMBER" - - node = nexus.get_node_at_nxdl_path("/ENTRY/coordinate_system_set", elem=elem) - assert node.attrib["type"] == "NXcoordinate_system_set" - - nxdl_file_path = os.path.join( - local_dir, "../../contributed_definitions/NXiv_temp.nxdl.xml" - ) - elem = ET.parse(nxdl_file_path).getroot() - node = nexus.get_node_at_nxdl_path( - "/ENTRY/INSTRUMENT/ENVIRONMENT/voltage_controller", elem=elem - ) - assert node.attrib["name"] == "voltage_controller" - - node = nexus.get_node_at_nxdl_path( - "/ENTRY/INSTRUMENT/ENVIRONMENT/voltage_controller/calibration_time", elem=elem - ) - assert node.attrib["name"] == "calibration_time" - def test_get_inherited_nodes(): """Test to verify if we receive the right XML element list for a given NXDL path.""" local_dir = os.path.abspath(os.path.dirname(__file__)) - nxdl_file_path = os.path.join(local_dir, "./NXtest.nxdl.xml") elem = ET.parse(nxdl_file_path).getroot() (_, _, elist) = nexus.get_inherited_nodes(nxdl_path="/ENTRY/NXODD_name", elem=elem) assert len(elist) == 3 - - nxdl_file_path = os.path.join( - local_dir, "../../contributed_definitions/NXiv_temp.nxdl.xml" - ) - - elem = ET.parse(nxdl_file_path).getroot() - (_, _, elist) = nexus.get_inherited_nodes( - nxdl_path="/ENTRY/INSTRUMENT/ENVIRONMENT", elem=elem - ) - assert len(elist) == 3 - - (_, _, elist) = nexus.get_inherited_nodes( - nxdl_path="/ENTRY/INSTRUMENT/ENVIRONMENT/voltage_controller", elem=elem - ) - assert len(elist) == 4 - - (_, _, elist) = nexus.get_inherited_nodes( - nxdl_path="/ENTRY/INSTRUMENT/ENVIRONMENT/voltage_controller", - nx_name="NXiv_temp", - ) - assert len(elist) == 4 - - -@pytest.mark.parametrize( - "hdf_name,concept_name,should_fit", - [ - ("source_pump", "sourceType", False), - ("source_pump", "sourceTYPE", True), - ("source pump", "sourceTYPE", False), - ("source", "sourceTYPE", False), - ("source123", "SOURCE", True), - ("1source", "SOURCE", True), - ("_source", "SOURCE", True), - ("same_name", "same_name", True), - ("angular_energy_resolution", "angularNresolution", True), - ("angularresolution", "angularNresolution", False), - ("Name with some whitespaces in it", "ENTRY", False), - ("simple_name", "TEST", True), - (".test", "TEST", False), - ], -) -def test_namefitting(hdf_name, concept_name, should_fit): - """Test namefitting of nexus concept names""" - if should_fit: - assert nexus.get_nx_namefit(hdf_name, concept_name) > -1 - else: - assert nexus.get_nx_namefit(hdf_name, concept_name) == -1 - - -@pytest.mark.parametrize( - "hdf_name,concept_name, score", - [ - ("test_name", "TEST_name", 9), - ("te_name", "TEST_name", 7), - ("my_other_name", "TEST_name", 5), - ("test_name", "test_name", 18), - ("test_other", "test_name", -1), - ("my_fancy_yet_long_name", "my_SOME_name", 8), - ("something", "XXXX", 0), - ("something", "OTHER", 1), - ], -) -def test_namefitting_scores(hdf_name, concept_name, score): - """Test namefitting of nexus concept names""" - assert nexus.get_nx_namefit(hdf_name, concept_name) == score - - -@pytest.mark.parametrize( - "better_fit,better_ref,worse_fit,worse_ref", - [ - ("sourcetype", "sourceTYPE", "source_pump", "sourceTYPE"), - ("source_pump", "sourceTYPE", "source_pump", "TEST"), - ], -) -def test_namefitting_precedence(better_fit, better_ref, worse_fit, worse_ref): - """Test if namefitting follows proper precedence rules""" - - assert nexus.get_nx_namefit(better_fit, better_ref) > nexus.get_nx_namefit( - worse_fit, worse_ref - ) - - -@pytest.mark.parametrize( - "string_obj, decode, expected", - [ - # Test with lists of bytes and strings - ([b"bytes", "string"], True, ["bytes", "string"]), - ([b"bytes", "string"], False, [b"bytes", "string"]), - ([b"bytes", b"more_bytes", "string"], True, ["bytes", "more_bytes", "string"]), - ( - [b"bytes", b"more_bytes", "string"], - False, - [b"bytes", b"more_bytes", "string"], - ), - ([b"fixed", b"length", b"strings"], True, ["fixed", "length", "strings"]), - ([b"fixed", b"length", b"strings"], False, [b"fixed", b"length", b"strings"]), - # Test with nested lists - ([[b"nested1"], [b"nested2"]], True, [["nested1"], ["nested2"]]), - ([[b"nested1"], [b"nested2"]], False, [[b"nested1"], [b"nested2"]]), - # Test with bytes - (b"single", True, "single"), - (b"single", False, b"single"), - # Test with str - ("single", True, "single"), - ("single", False, "single"), - # Test with int - (123, True, 123), - (123, False, 123), - ], -) -def test_decode_or_not(string_obj, decode, expected): - # Handle normal cases - result = nexus.decode_or_not(elem=string_obj, decode=decode) - if isinstance(expected, list): - assert isinstance(result, list), f"Expected list, but got {type(result)}" - # Handle all other cases - else: - assert result == expected, f"Failed for {string_obj} with decode={decode}" diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index 3abf139c3..ebb7ce62a 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -1,56 +1,17 @@ # pylint: disable=too-many-lines -"""Parse NeXus definition files""" +"""Parse NeXus definition files +""" import os -import re import textwrap from functools import lru_cache from glob import glob from pathlib import Path -from typing import List -from typing import Optional import lxml.etree as ET from lxml.etree import ParseError as xmlER -def decode_or_not(elem, encoding: str = "utf-8", decode: bool = True): - """ - Decodes a byte array to a string if necessary. All other types are returned untouched. - If `decode` is False, the initial value is returned without decoding, including for byte arrays. - - Args: - elem: Any Python object that may need decoding. - encoding: The encoding scheme to use. Default is "utf-8". - decode: A boolean flag indicating whether to perform decoding. - - Returns: - A decoded string (in case of a byte string) or the initial value. - If `decode` is False, always returns the initial value. - - Raises: - ValueError: If a byte string cannot be decoded using the provided encoding. - """ - if not decode: - return elem - - # Handle lists of bytes or strings - elif isinstance(elem, list): - if not elem: - return elem # Return an empty list unchanged - - decoded_list = [decode_or_not(x, encoding, decode) for x in elem] - return decoded_list - - if isinstance(elem, bytes): - try: - return elem.decode(encoding) - except UnicodeDecodeError as e: - raise ValueError(f"Error decoding bytes: {e}") - - return elem - - def remove_namespace_from_tag(tag): """Helper function to remove the namespace from an XML tag.""" @@ -84,8 +45,8 @@ def get_app_defs_names(): Path(nexus_def_path) / "contributed_definitions" / "*.nxdl.xml" ) - files = sorted(glob(str(app_def_path_glob))) - for nexus_file in sorted(glob(str(contrib_def_path_glob))): + files = sorted(glob(app_def_path_glob)) + for nexus_file in sorted(contrib_def_path_glob): root = get_xml_root(nexus_file) if root.attrib["category"] == "application": files.append(nexus_file) @@ -131,13 +92,7 @@ def get_hdf_info_parent(hdf_info): """Get the hdf_info for the parent of an hdf_node in an hdf_info""" if "hdf_path" not in hdf_info: return {"hdf_node": hdf_info["hdf_node"].parent} - node = ( - get_hdf_root(hdf_info["hdf_node"]) - if "hdf_root" not in hdf_info - else hdf_info["hdf_root"] - ) - for child_name in hdf_info["hdf_path"].split("/")[1:-1]: - node = node[child_name] + node = get_hdf_parent(hdf_info) return {"hdf_node": node, "hdf_path": get_parent_path(hdf_info["hdf_path"])} @@ -148,71 +103,33 @@ def get_nx_class(nxdl_elem): return nxdl_elem.attrib.get("type", "NX_CHAR") -def get_nx_namefit(hdf_name: str, name: str, name_any: bool = False) -> int: - """ - Checks if an HDF5 node name corresponds to a child of the NXDL element. - A group of uppercase letters anywhere in the name is treated as freely choosable - part of this name. - If a match is found this function returns twice the length for an exact match, - otherwise the number of matching characters (case insensitive) or zero, if - `name_any` is set to True, is returned. - All uppercase groups are considered independently. - Lowercase matches are independent of uppercase group lengths, e.g., - an hdf_name `get_nx_namefit("my_fancy_yet_long_name", "my_SOME_name")` would - return a score of 8 for the lowercase matches `my_..._name`. - All characters in `[a-zA-Z0-9_.]` are considered for matching to an uppercase letter. - If you use any other letter in the name, it will not match and return -1. - Periods at the beginning or end of the hdf_name are not allowed, only exact - matches will be considered. - - Examples: - - * `get_nx_namefit("test_name", "TEST_name")` returns 9 - * `get_nx_namefit("te_name", "TEST_name")` returns 7 - * `get_nx_namefit("my_other_name", "TEST_name")` returns 5 - * `get_nx_namefit("test_name", "test_name")` returns 18 - * `get_nx_namefit("test_other", "test_name")` returns -1 - * `get_nx_namefit("something", "XXXX")` returns 0 - * `get_nx_namefit("something", "OTHER")` returns 1 - - Args: - hdf_name (str): The hdf_name, containing the name of the HDF5 node. - name (str): The concept name to match against. - name_any (bool, optional): - Accept any name and return either 0 (match) or -1 (no match). - Defaults to False. - - Returns: - int: -1 if no match is found or the number of matching - characters (case insensitive). - """ - path_regex = r"([a-zA-Z0-9_.]+)" - +def get_nx_namefit(hdf_name, name, name_any=False): + """Checks if an HDF5 node name corresponds to a child of the NXDL element + uppercase letters in front can be replaced by arbitrary name, but + uppercase to lowercase match is preferred, + so such match is counted as a measure of the fit""" if name == hdf_name: return len(name) * 2 - if hdf_name.startswith(".") or hdf_name.endswith("."): - # Don't match anything with a dot at the beginning or end - return -1 - - uppercase_parts = re.findall(r"[A-Z]+(?:_[A-Z]+)*", name) - - regex_name = name - uppercase_count = 0 - for up in uppercase_parts: - uppercase_count += len(up) - regex_name = regex_name.replace(up, path_regex) - - name_match = re.search(rf"^{regex_name}$", hdf_name) - if name_match is None: - return 0 if name_any else -1 - - match_count = 0 - for uppercase, match in zip(uppercase_parts, name_match.groups()): - for s1, s2 in zip(uppercase.upper(), match.upper()): - if s1 == s2: - match_count += 1 - - return len(name) + match_count - uppercase_count + # count leading capitals + counting = 0 + while counting < len(name) and name[counting].isupper(): + counting += 1 + if ( + name_any + or counting == len(name) + or (counting > 0 and hdf_name.endswith(name[counting:])) + ): # if potential fit + # count the matching chars + fit = 0 + for i in range(min(counting, len(hdf_name))): + if hdf_name[i].upper() == name[i]: + fit += 1 + else: + break + if fit == min(counting, len(hdf_name)): # accept only full fits as better fits + return fit + return 0 + return -1 # no fit def get_nx_classes(): @@ -383,6 +300,18 @@ def get_own_nxdl_child( name - nxdl name class_type - nxdl type or hdf classname (for groups, it is obligatory) hdf_name - hdf name""" + for child in nxdl_elem: + if not isinstance(child.tag, str): + continue + if child.attrib.get("name") == name: + return set_nxdlpath(child, nxdl_elem) + for child in nxdl_elem: + if not isinstance(child.tag, str): + continue + if child.attrib.get("name") == name: + child.set("nxdlbase", nxdl_elem.get("nxdlbase")) + return child + for child in nxdl_elem: if not isinstance(child.tag, str): continue @@ -472,7 +401,7 @@ def get_required_string(nxdl_elem): def write_doc_string(logger, doc, attr): """Simple function that prints a line in the logger if doc exists""" if doc: - logger.debug(f"@{attr} [NX_CHAR]") + logger.debug("@%s [NX_CHAR]", attr) return logger, doc, attr @@ -624,15 +553,13 @@ def get_doc(node, ntype, nxhtml, nxpath): doc_field = node.find("doc") if doc_field is not None: doc = doc_field.text - enums = get_enums(node) # enums - if enums is not None: + (index, enums) = get_enums(node) # enums + if index: enum_str = ( "\n " - + ("Possible values:" if len(enums) > 1 else "Obligatory value:") + + ("Possible values:" if enums.count(",") else "Obligatory value:") + "\n " - + "[" - + ",".join(enums) - + "]" + + enums + "\n" ) else: @@ -662,26 +589,20 @@ def get_namespace(element): return element.tag[element.tag.index("{") : element.tag.rindex("}") + 1] -def get_enums(node: ET._Element) -> Optional[List[str]]: - """ - Makes list of enumerations, if node contains any. - - Args: - node (ET._Element): The node to check for enumerations. - - Returns: - Optional[List[str]]: - Returns a list of the enumeration values if an enumeration was found. - If no enumeration was found it returns None. - """ +def get_enums(node): + """Makes list of enumerations, if node contains any. + Returns comma separated STRING of enumeration values, if there are enum tag, + otherwise empty string.""" + # collect item values from enumeration tag, if any namespace = get_namespace(node) enums = [] for enumeration in node.findall(f"{namespace}enumeration"): for item in enumeration.findall(f"{namespace}item"): enums.append(item.attrib["value"]) - if enums: - return enums - return None + enums = ",".join(enums) + if enums != "": + return (True, "[" + enums + "]") + return (False, "") # if there is no enumeration tag, returns empty string def add_base_classes(elist, nx_name=None, elem: ET.Element = None): @@ -809,7 +730,7 @@ def get_best_child(nxdl_elem, hdf_node, hdf_name, hdf_class_name, nexus_type): and nxdl_elem.attrib["name"] == "NXdata" and hdf_node is not None and hdf_node.parent is not None - and decode_or_not(hdf_node.parent.attrs.get("NX_class")) == "NXdata" + and hdf_node.parent.attrs.get("NX_class") == "NXdata" ): (fnd_child, fit) = get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name) if fnd_child is not None: @@ -900,9 +821,6 @@ def get_node_at_nxdl_path( we are looking for or the root elem from a previously loaded NXDL file and finds the corresponding XML element with the needed attributes.""" try: - if nxdl_path.count("/") == 1 and not nxdl_path.upper().startswith("/ENTRY"): - elem = None - nx_name = "NXroot" (class_path, nxdlpath, elist) = get_inherited_nodes(nxdl_path, nx_name, elem) except ValueError as value_error: if exc: diff --git a/manual/source/classes/applications/apm-structure.rst b/manual/source/classes/applications/apm-structure.rst deleted file mode 100644 index dd6c45662..000000000 --- a/manual/source/classes/applications/apm-structure.rst +++ /dev/null @@ -1,284 +0,0 @@ -.. _Apm-Structure-APP: - -===================== -Atom-probe tomography -===================== - -.. index:: - IntroductionApm - ApmAppDef - ApmBC - StatusQuoApm - ApmParaprobeAppDef - ApmGermanNfdi - -.. _IntroductionApm-APP: - -Introduction -############ - -Set of data schemas to describe the acquisition, i.e. measurement side, the extraction of hits from detector raw data, -steps to compute mass-to-charge state ratios from uncorrected time of flight data, the reconstruction, and the ranging, i.e. identification of peaks in the mass-to-charge-state ratio histogram to detect (molecular) ions. -The data schemas can be useful to generate data artifacts also for field-ion microscopy experiments. - -.. _ApmAppDef-APP: - -Application Definition -###################### - - :ref:`NXapm`: - A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes in a process called ranging. The structure of the schema has been designed to also document a simulation of an atom probe - experiment. Having a combined schema for the measurement and the simulation is beneficial to document that - there are many similarities between the measurement and a computer simulation of it. - -.. _ApmBC-APP: - -Base Classes -############ - -The following base classes are proposed to support modularizing the storage of pieces of information: - - :ref:`NXchamber`: - A base class to describe a component of the instrument which houses other components. - A chamber may offer a controlled atmosphere to execute an experiment and/or offer functionalities - for storing and loading specimens. - - :ref:`NXcoordinate_system_set`, :ref:`NXcoordinate_system`: - Base classes to describe different coordinate systems used and/or to be harmonized - or transformed into one another when interpreting the dataset. - - :ref:`NXion`: (about to become replaced by :ref:`NXatom_set`) - A base class to describe molecular ions with an adjustable number of atoms/isotopes building each ion. - For the usage in atom probe research the maximum number of atoms supported building a molecular ion - is currently set to a maximum of 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with - which all possible nuclides (stable, radioactive, or synthetically generated ones) can be described. - - :ref:`NXfabrication`: - A base class to bundle manufacturer/technology-partner-specific details about - a component or device of an instrument. - - :ref:`NXpeak`: (about to become complemented by NXpeak_fitting) - A base class to describe peaks mathematically to detail how peaks in - mass-to-charge-state ratio histograms (aka mass spectra) are defined and - labelled as iontypes. - - :ref:`NXpump`: - A base class to describe details about pump(s) used as components of an instrument. - - :ref:`NXpulser_apm`: - A base class to describe the high-voltage and/or laser pulsing capabilities. - - :ref:`NXreflectron`: - A base class to describe a kinetic-energy-sensitive filtering device - for time-of-flight (ToF) mass spectrometry. - - :ref:`NXstage_lab`: - A base class to describe the specimen fixture including the cryo-head. - Nowadays, stages of microscopes represent small-scale laboratory platforms. - Therefore, there is a need to define the characteristics of such stages in more detail, - especially in light of in-situ experiments. Many similarities exists between a stage - in an electron microscope and one in an atom probe instrument. Both offer fixture - functionalities and additional components for applying e.g. stimuli on the specimen. - -Microscopy experiments, not only taking into account those performed on commercial instruments, offer users to apply a set of -data processing steps. Some of them are frequently applied on-the-fly. For now we represent these steps with specifically named -instances of the :ref:`NXprocess` base class. - -Several base classes were defined to document processing of atom probe data with established algorithms: - - :ref:`NXapm_hit_finding`: - A base class to describe hit finding algorithm. - - :ref:`NXapm_volt_and_bowl`: - A base class to describe the voltage-and-bowl correction. - - :ref:`NXapm_charge_state_analysis`: - A base class to document the resolving of the charge_state. - - :ref:`NXapm_reconstruction`: - A base class to document the tomographic reconstruction algorithm. - - :ref:`NXapm_ranging`: - A base class to document the ranging process. - - :ref:`NXapm_msr`, :ref:`NXapm_sim`: - Respective base classes that serve as templates to compose the :ref:`NXapm` application definition from. - -These base classes are examples that substantiate that data processing steps are essential to transform atom probe measurements or simulations into knowledge. Therefore, these steps should be documented -to enable reproducible research, if possible even numerical reproducibility of the results, -and learn how pieces of information are connected. In what follows, an example is presented how an -open-source community software can be modified to use descriptions of these computational steps. - -A detailed inspection of spatial and other type of filters frequently used in analysis of atom probe -data revealed that it is better to define atom-probe-agnostic reusable concepts for filters: - - :ref:`NXspatial_filter`: - A base class proposing how a point cloud can be spatially filtered in a specific yet general manner. - This base class takes advantage of :ref:`NXcg_ellipsoid_set`, :ref:`NXcg_cylinder_set`, - and :ref:`NXcg_hexahedron_set` to cater for commonly used geometric primitives in atom probe. - The primitives are used for defining the shape and extent of a region of interest (ROI). - - :ref:`NXsubsampling_filter`: - A base class for a filter that can also be used for specifying how entries - like ions can be filtered via sub-sampling. - - :ref:`NXmatch_filter`: - A base class for a filter that can also be used for specifying how entries - like ions can be filtered based on their type or other descriptors like hit multiplicity. - -The respective research software here is the `paraprobe-toolbox `_ -The software is developed by `M. Kühbach et al. `_. -For atom probe research the proposal can also serve as a blue print how computational steps of other software -tool including commercial ones could be developed further to benefit from NeXus. - -.. _IntroductionApmParaprobe-APP: - -apmtools -######## - -The paraprobe-toolbox is an example of an open-source parallelized software for analyzing -point cloud data, for assessing meshes in 3D continuum space, and for studying the effects of -parameterization on descriptors of micro- and nanoscale structural features (crystal defects) -within materials when characterized and studied with atom probe. - -The need for a thorough documentation of the tools in not only the paraprobe-toolbox -was motivated by several needs: - -First, users of software would like to better understand and also be able to study for themselves -which individual parameters and settings for each tool exist and how configuring these -affects analyses quantitatively. This stresses the aspect how to improve documentation. - -Second, scientific software like paraprobe-toolbox implement numerical/algorithmical -(computational) workflows whereby data coming from multiple input sources -(like previous analysis results) are processed and carried through more involved analyses -within several steps inside the tool. The tool then creates output as files. This -provenance and workflow should be documented. - -Individual tools of paraprobe-toolbox are developed in C/C++ and/or Python. -Provenance tracking is useful as it is one component and requirement for making -workflows exactly numerically reproducible and thus to enable reproducibility (the "R" -of the FAIR principles of data stewardship). - -For tools of the paraprobe-toolbox each workflow step is a pair or triple of sub-steps: -1. The creation of a configuration file. -2. The actual analysis using the Python/or C/C++ tools. -3. The optional analyses/visualization of the results based on data in NeXus/HDF5 files generated by each tool. - -.. _StatusQuoApm-APP: - -What has been achieved so far? -############################## - -This proposal summarizes work of members of the FAIRmat project, which is part of the `German -National Research Data Infrastructure `_. The here detailed -proposal documents how all tools of the paraprobe-toolbox were modified to generate -only well-defined configuration files as accepted input and yield specifically formatted output -files according to the following NeXus application definitions. - -Data and metadata between the tools are exchanged with NeXus/HDF5 files. This means that data -inside HDF5 binary containers are named, formatted, and hierarchically structured according -to application definitions. - -For example the application definition NXapm_paraprobe_config_surfacer specifies -how a configuration file for the paraprobe-surfacer tool should be formatted -and which parameters it contains including optionality and cardinality constraints. - -Thereby, each config file uses a controlled vocabulary of terms. Furthermore, -the config files store a SHA256 checksum for each input file. This implements a full -provenance tracking on the input files along the workflow. - -As an example, a user may first range their reconstruction and then compute spatial -correlation functions. The config file for the ranging tool stores the files -which hold the reconstructed ion position and ranging definitions. -The ranging tool generates a results file with the labels of each molecular ion. -This results file is formatted according to the tool-specific `results` -application definition. The generated results file and the reconstruction is -imported by the spatial statistics tool which again keeps track of all files -and reports its results in a spatial statistics tool results file. - -This design makes it possible to rigorously trace which numerical results were achieved -with specific inputs and settings using specifically-versioned tools. Noteworthy -this includes Y-junction on a graph which is where multiple input sources are -combined to generate new results. - -We are convinced that defining, documenting, using, and sharing application definitions -is useful and future-proof strategy for software development and data analyses as it enables -automated provenance tracking which happens silently in the background. - -Base classes have been defined to group common pieces of information for each tool of the -toolbox. For each tool we define a pair of base classes. One for the configuration (input) side -and one for the results (output) side: - - :ref:`NXapm_paraprobe_tool_config`, :ref:`NXapm_paraprobe_tool_results`, :ref:`NXapm_paraprobe_tool_common`: - Configuration, results, and common parts respectively useful for the application definitions for tools of the paraprobe-toolbox. - -.. _ApmParaprobeAppDef-APP: - -Application Definitions -####################### - -NXapm_paraprobe application definitions are in fact pairs of application definitions. -One for the configuration (input) side and one for the results (output) side. For each -tool one such pair is proposed: - - :ref:`NXapm_paraprobe_transcoder_config`, :ref:`NXapm_paraprobe_transcoder_results`: - Configuration and the results respectively of the paraprobe-transcoder tool. - Load POS, ePOS, APSuite APT, RRNG, RNG, and NeXus NXapm files. - Store reconstructed positions, ions, and charge states. - - :ref:`NXapm_paraprobe_ranger_config`, :ref:`NXapm_paraprobe_ranger_results`: - Configuration and results respectively of the paraprobe-ranger tool. - Apply ranging definitions and explore possible molecular ions. - Store applied ranging definitions and combinatorial analyses of possible iontypes. - - :ref:`NXapm_paraprobe_selector_config`, :ref:`NXapm_paraprobe_selector_results`: - Configuration and results respectively of the paraprobe-selector tool. - Defining complex spatial regions-of-interest to filter reconstructed datasets. - Store which points are inside or on the boundary of complex spatial regions-of-interest. - - :ref:`NXapm_paraprobe_surfacer_config`, :ref:`NXapm_paraprobe_surfacer_results`: - Configuration and results respectively of the paraprobe-surfacer tool. - Create a model for the edge of a point cloud via convex hulls, alpha shapes, or alpha-wrappings. - Store triangulated surface meshes of models for the edge of a dataset. - - :ref:`NXapm_paraprobe_distancer_config`, :ref:`NXapm_paraprobe_distancer_results`: - Configuration and results respectively of the paraprobe-distancer tool. - Compute and store analytical distances between ions to a set of triangles. - - :ref:`NXapm_paraprobe_tessellator_config`, :ref:`NXapm_paraprobe_tessellator_results`: - Configuration and results respectively of the paraprobe-tessellator tool. - Compute and store Voronoi cells and properties of these for all ions in a dataset. - - :ref:`NXapm_paraprobe_spatstat_config`, :ref:`NXapm_paraprobe_spatstat_results`: - Configuration and results respectively of the paraprobe-spatstat tool. - Compute spatial statistics on the entire or selected regions of the reconstructed dataset. - - :ref:`NXapm_paraprobe_clusterer_config`, :ref:`NXapm_paraprobe_clusterer_results`: - Configuration and results resepctively of the paraprobe-clusterer tool. - Compute cluster analyses with established machine learning algorithms using CPU or GPUs. - - :ref:`NXapm_paraprobe_nanochem_config`, :ref:`NXapm_paraprobe_nanochem_results`: - Configuration and results resepctively of the paraprobe-nanochem tool. - Compute delocalization, iso-surfaces, analyze 3D objects, composition profiles, and mesh interfaces. - - :ref:`NXapm_paraprobe_intersector_config`, :ref:`NXapm_paraprobe_intersector_results`: - Configuration and results resepctively of the paraprobe-intersector tool. - Analyze volumetric intersections and proximity of 3D objects discretized as triangulated surface meshes - in continuum space to study the effect the parameterization of surface extraction algorithms on the resulting shape, - spatial arrangement, and colocation of 3D objects via graph-based techniques. - -.. _ApmGermanNfdi-APP: - -Joint work German NFDI consortia NFDI-MatWerk and FAIRmat -####################################################################### - -Members of the NFDI-MatWerk and the FAIRmat consortium of the German National Research Data Infrastructure -are working together within the Infrastructure Use Case IUC09 of the NFDI-MatWerk project to work on examples -how software tools in both consortia become better documented and interoperable to use. Within this project, -we have also added the `CompositionSpace tool that has been developed at the Max-Planck-Institut für Eisenforschung -GmbH in Düsseldorf `_ by A. Saxena et al. - -Specifically, within the IUC09 we refactored the code base behind the publication `A. Saxena et al. `_ to better document its configuration, here as an example implemented like for the above-mentioned paraprobe-toolbox using NeXus: - - :ref:`NXapm_compositionspace_config`, :ref:`NXapm_compositionspace_results`: - Configuration and the results respectively of the CompositionSpace tool. diff --git a/manual/source/classes/applications/container/ComplexContainerBeampath.png b/manual/source/classes/applications/container/ComplexContainerBeampath.png deleted file mode 100644 index 597cee834c0426bd0e60b1afbf6554a5f3b04a99..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 7089 zcmbVxgT!j8lW(I7CP9R3l4E<2>J5 z)AI_IpP{<#g$8#av2ACx&qHz?7*6{wc9+~vb1nw=8zsvCGZ@1U!ma35{YCTeb^go#}G;SGXdmMbu z&k(dLz+>M0rk*>Sf)`6r0rqXS-WdWA6B8%4ZJE%EdqQPyjwzkRB;aOHTl>4)o5x|d zk^nCj4;eIl%(n^F+aGp�Z2d70QK#NZGhGGt4!*DVv+aK@%#_`tEYYN5riu(%l4#$J*D7^Wj?wMl{e?}qh~ zY>s%K&(C)zD>TXgDhM0}O&=C2r+yy#K3pp3G_SZgw*E;r78oa{=-eoZRr2X4M1X%T zpwKhuUnefLT1P?+p*cUDbF;27;urNXIdV3GP9r`-Tm1Iz!5axr2q&_2aKHv)6R*sV zoC86Z4ZQcMBBg7vGph*EBH-3c92|H`VKT=wJcAF`QUTL~RppiMF@&7l+%|jh=q_Yl zl(4Ai%5;s*CbbwAZH2$YiG@Y5cQ^ujWfjnl_}!#bRb1n>F}OTlrVE!&9&uFk^!!4^ z;FHzbDye5^Xk#UxwXh=zxB3+h)q$p^rRmjVynV~|G~Rjyp=(MM0mu_vg>= zxp&taB#b47RTc~^Sn`WBaGB9RJ~<@SMf)iaypK+F>MgC7zsG<%r}Pqabh%S?=ZlnO z^3i`NU#PHfxzukcD5suN`yh?Xm0-C9poTO!`bZon&_&qD+`{Bx!n8>beH987Qkx%6 zRNOt{;*|T%y-h7HKpqjqJ|6|a$DY4jlDeCYdZAn2&+t{t*H<)>RWW_m=_B!yXoyoi~j%|VXyXk z04CaDLB0Woc^Km9>6tgSGvc<^MsnrPilHHjLv>{cIk;b)x=dF3^O!*;WI(#z7`=S_P(B*fsh&^#>LCqbFwo<4%S1-m5+rtCdO_86H82|ZC-J$ z^0QbYQ`^F#vI*`-R!K??acY7!^%XsR4*+eK%Hj)EVh@1o1ZacHTr3XZeXE%-cJZ^~ z?igTnbhO%Wgc-Tl^we?eguId(P0owu>bd@t3XpYIWGuOgQ3;QMy?OJ-3M_sY35mfq zuL>o*x~!TS!N0WzGR3%G{DKF@zLYPS60_t>W-)`#e=IG9h1bEVcPafZw@P#@ERv6p zy`y8B4KrpKCaWw_2M6wwSG%=MfhV6$c;?N^>W7f6Z-J zDZ9VEuFcES$qeV@;ra2!?iU#qRgB+afU-yn!0$B5%45;`0FQ+Jpvg1>NBLMTz?jA| z)(osl*JpZq(Vf!EzRs{Z#ZpRbFK?ztkBILl;4p?=3tZpa=+|-|^w7C6v9sgywH;Fs z5D@4!^2MZlIShqt{M-5$5}9@b3BTNuH88kO!XO#foj}bZFw%z41MhYee!kk11Oklz z`dh>Fa}3e4#Q&K^U0w$2y?M`4s?}sm*A~AeYh%N5dpXtdeQ1dE*Lyz0`5f+^M4G6z zHCqtGR@VAntA~)o{%h9k?(R;MI#dUbIHEcyL@Z3EPxQq*VzL9^&^mv_@!);Obxb`s0N9NAtehd-L8uV}6C42C7z=Ib>PI6$H_DA_up%NN{Fh^> z@6}Hj#FD_{!Tfx_zu5NJ|A5Ka53{$5E!*l!AM|fiPAus(m+^;m79F8dyynf(?=1rH zL1Z)>HwZHN>dAH-*ru$A9m`(xn;An7#+IpHMW`trs;7o`dodKo%*qNKlD;Z0@SS}M zHU)v8)BotDgVO^R+R17TGolBVnK8I7s(9m@l)VE3NI5x(eSbQnP-m9fpg%(h52&{L zb-y_Dz`Ik#*O}nHg zNlM)8!9#x}(&v1I@WQ?csp#Kj<(@;5C9WOi9N+_lr(szFV>MwNGCcRs0*lZ|JIVP9 zA=!WCs+T1Mg;0=m61V*fl8wT){%kq|Mn?2fwDZ(fo$MHgwK`?lUyM`_1(0Ukfxp`(RR^z-IUr-0Hi-PWow{Cu;JB3(UcuYs*w zS4*6aR_LvhhkwGVo|nTL3j)wU85OH)F@&*_VhEf6T494$f9%^o{wW)R-E2MjvGeza zFSC{4jJ5&0C5fpaM@X8+x{0vKT$s9P6dx_!2}!7${-?<)v7eVYfycvLXmo&twy8~2 zSzgxcRWV?%+mDKmCxGJOHY}zf zBEzVtsQQD4x4pr}DhW>kTOQr`_F+|Id_uJWpE4krDs1n$j^ z4~#^#*Vo<6%_-@S^o6&xx9o;ptbyqcres_rlnA$?e4mR+7B4CynP7Ygfwge$eLz}V zGHzyvt(_DOG`TG4bC_tSFx*_?tgdwH@@G^c9{#)#bZ|j__6fymYZZ3A(t^oZFRLDJ z<|7pqNdZ|D!)U?g&d%b-{%;MSR7p(6^ymT)h)QkekSh-{N&J1hTjn*>H)-(^OFEn3 zfYf#FlAvDXSZH;}`L!fzojkUZ-u6h1~<|ldl38{cs(Tz z^yf0hlCvn;jF)zoekSZnWBb{^yuUDabL6)Zuf3|k>+R2D zMvZ^Gh-lu&y-J9rKP7y=AV`reWqLvN9_W;5A}8f@GEIFJ>MP(|aY1j>ljymVg<{x4 zjTFww#AKCVyAHqe?wr(PU0Yvgn<*~*(cO)Zkf1efbUo?C5fXKog#!N9hvflQ_Ei@1S=cn*o&~0NkFVWeV!*?(Mf@_YaIXRWBoSN8N{9R{?_E)?I0Pl)- zSk3-lc6VCwGx2l6)(wj|_KY$|AtH*hpC?w_!mj9Eym)c1V@Ac9UMldOv9Ym=hDLYW znZ#o0TO2BlDK1H~Tb&O}SYUmu{fUFUp;BFPRH*QlWfB*sA(cD;7K8SsKm<0T%Jh2< zl25-sW)G5-%1!FyUy%-yRq84#LT$7pDM1{kASaKA|J*&W{>_j1Bet3!Q3ERr3${`r zxt8<=t9tQd$(x@834HBwAge03Xrmn&8TmB#UY;zXJtTXHv-mT3HX4_wdxXvk*q_u~ zB^KOt1>j_xQ&o(Mfjf`PTK&m~q|UNl_(H6f+C%*J+s^o{zeB+URn(uW&@u3)lKb|J z;p;&>2N*w%=;1HNUykTZO0!8|{kbxXs;a8Jy}g~u@F#jT#yUC?U%fU8K$QTFg)4oE z%_J{+UxjhaAyD}a+Cs@wwyCv08}-sKhMprLBO|M=zF~n3htt&!q@|o7$!ghePmm7z z=+^r^QYn-8Z8ux1OeYQ)J;h$WBE@i|1QQu8Z9J*;IbdgJ7r&Ia))|34-QYs^?AbGZ z=Sd!<%U1ubM*O7q$3I697l{b1@r}c zb#YGrIZ^e>4+;7>IyR=G?@1{o-#w>byhE2awIfv-SjnB5>qWm1bS$f`p7=skW1XFT zab*!&nTEAa*pl^45h`few>x}ywmtEbT}whUI9L)~CN=kUf=-|A2g^ng;RDWaM3N{S zftMEMw&v9*0uNO={Kbrmkq%3Z5NXTI?3koyUB@P}H98^f}=x3TKl?q2}O2mR_|A|nL zG%`hFHXWWohRc4KLB~t}UJ|dtfA+lL(mfBsorQsVS4B-NvMQG`*|mrnY;qfg*hFN{ zAVt)=7mvOnW!V#zSZ;&1_0}9V3d%PhmV*IWUO1bT7+5{`@uWt=L$Aen^UF!p7wjLOt42~RsEI<~v438pG3D_0z4+^UFEz|`) zvuD@Lii^O;!@>~8S9gxNMoiLx4hhjF6<`Q53Q7mdctdkR2MJQ(Hb3194@9I}(Z6jDB zJ-!i-Y^d~bBcC&hzN{R&7{>TGfa3hb5Hl;n^pGGf31?*`JccmBb>U5|n<%zhE5z0o zFs#D*K1$Z!-dX3=Ia(A>%e}X|NL+4)pCwH^KJlswMT6a+iTAMxVxlBhGDD=E4w!Xl zR`oTwY|rFK!#R0fgRZJNaIvu794Qm5yb=~B`#Y=?lD|D9mB+$H zGGJ}T z>oxbA*&q6uHWjLhk7x@@K%-tEY!@WtNf=nyYKLH|PiyahN^|b2kcg7p`!3!)O1;1M zD8B@WA@E4Zz66RO5QvrA8XNqw&$>ONTwlKIRz-bacHh*#f`TAOsjnZcp1tkwDX9tt zZ{qN8LFksZFmv_H?%aH{-5m}-3H#ct$VIS<=6#fu9l;H<{q^2lw`hBNw4T9Fhg>pw z-#_9?|jjKcL2)~hIOYm38(_cRw(@DuF$S@N9u3V*z!Az)-2&b_hHdUq^ z3xAG=x_$BS|6XF^xpYf4D&8f*`ZGCZZ*GH5cAFtri0_{bBW7wN&i!X;U;vBKFoUaB z6dC4ff2%rVim5w%$osJCH6|G^oQf{XGA&-h3Vz9;(IbvVh*_!@a$6 zyTloD+(iBw#EpzJ3i{pq)k`)&d?7g=D>&G!kx|lUUOLEtfpK)Sl+m;S2)lf}(;y}2HdDyC+iQAu1*gEi}#v~#)tauKr>f77x zt6>sJhdB3RN6g7o#Nn!O5c2@$o2<(txGSh4PEM)$;^+L99-&Aj;AE5vj1>sQN8#5B zF>QemN{)ubKP~$|T#CZT>1e}^Yd5Ps9XV5SNamaJ%QYO<)?X+s!HDn+>w zgkDCoQRbQqMq)6TbMKLEM=HzKk<4|35{?o}k|!F4XAzn)`Jp=2rzD#7Y<@KZ9_6xr z9pG^flGkOg=6S@9K%*$XI8h=F4-3p?WM;QM;o1v@ECrnoCksU7yJVMox*z0C<2SkI zpI;8id|nc0`Y*%L>%eNNE3z$!^6!M<_Bk7b8p6h(>7>O`A0 z<+Zv*G%oobe{*ED{dM1NZ?PGvV#``j4cAc7NNPgGz!Dkv{TaS@;b(}yo^=0#PGFJz zZnL536YPaW4f$FI*7aZ8k+WfKpLp58WA|%}Q@wZTZb|N&MlBd(NM`?fsxmB0elg5a zyhTfzYtn^Y>O}{*Xk9rgF>z5nn_pVy(}ezLUu)}VJ-yP^B{+!VuV+ohkm{K0X1(jcKbDH?b&>a_(vxDPrweFG!4ZAQaM@IzzoNjj}rA zDd{kJNtN8Ib6~C!yRUCI`0r^kQiz=V_+lWl4sGU=mKMH|Lz&xg`au%S7JWZM-(ZyC zY#>w0b+bZ4{R69Ou8h`8GW{N}ZKwn{hbDlMWY(nFn;@L7Cww3hUttM6+E&%TSqy$H zO&vQlZoeprsc76h-5UFw_||P67JNj!psA8~0(<040j;#8ZhWd1PAZ)@XY#1pN)8>I z64k46S?F;kD#aHQ)0rptsTt&LEW5MFr}iV=DwtlH#MuJc^?~}{NW{(*GKiKKp`5JJSn=tL zWw`ym#rh3c5D}+>zU7-!QKX}9Q^r3wOy16eEhKnz|J>v1gl6sbZ`IcmKef_PdcMtKNSG<9Xx4}|=|E$9hEynSWZfFpV5_G*B%drKT zf{p37pZB$gbas&@46(47YZbb@8iCPEJw!2f+^TU{;OoX*ofcVd4Ci}K&W{udOOZ=t z#S%e0z1B4hVGwq$;tgot*W3B8oi}G=XMrnFctcBY#-FJdPMc3$vx24TVrm__`JV{r zWa$;L>gx-iP}rwlo)7P^BtBUGJ-T&NRCFAm0y}ZW$gYQY;R;z9O3Hq_ZqLg}D}5gC-$dChBeP#=_&Wpc z6)^{U=SlU}^T*LAGHTrz*Ap~tFkB5b#KBBH*19n!!Q|!N93nX5?j!e>NF|R`ZpIhF zfmx@Ej=QHU&3KG@J$PDno7xgmx2veFAUE;jl8Mo>b>~UIVQ`vsRSAk>_BorqYgesWGUr@`D=W&OA`>A)AQ05o^3v}i5Lh$_1g0Db0lX8X^R58= zdf_PfS`7(&c_EpEf#a8U@*f-_5PbCK9~ip&QWWqep_7c3ld7$mldF+~Da6&)mG!fY zrK7QtohhrW!>5!(VIl~G0`gi~Ld`98f5FvDO??sJ_>&oD^1wR}x|gq!KA*>kW5EVw zuUbm{adpZ^)|#v<)Y9k-VZzhDP{*;_)>cuIo~8+KLbAq6P{#TvKm7Nd=TnVILXyxI zl%HESKB7158}lhreFI-Shi*ud+gI%T>QLF(*pdb}OAZlKLK#?DW!>D|G+hJ3hT`Qk zUH!BpqoSlOEG)n~d3pyk6^H@?0(uLmRDw!Sw1tuBKgK6BpE8`C`NC!=5?;L}APMt; zaR+}E78d4#hJZ*#MU@cM>JN@+jO{4EQ73XtfufD`t#80g8K5T(wmmSFzPQ|niIO#% zUOgN34?|k1wVv~&`)qK;1#&U|SUpzI;H)JFc+BQ?Po4OrOMFz>WFf8o z9?c@2ej~~&m*e?<85w(3)Uwse+1)OJ5mUdcTO9zA|L5vGqJP89V4Q zLZPB^_-L2eM9r>zZP#fA*Ywo1dUUg(N4JSGKmb1D~NPY=dncQ+j0(tM>i z71eHtTc`hR$-q0qBmFFo^&dP6g{;}xe&oJ58oC&mDk$LbTt#kZ%08?1cO#%9_&ha! z=6r>TS=o|>yj!oBigB55F8cCxgpz^-)9q%XWDg%xg|BN_+0eZBF}=T!_U223F&dv=VeyWm~`2Y7bj>l_ksTBB;}*4 z>ovbvbPPNMuVab10~F*RHt0m-_7C7u{h#Nam|r;$`Vz9_J>_!8qVvNhmTZCJc^C9eHBn(jF{TXU6 z?l($^k2k|5du(8~I>BrOzJGatj(yyL-BO_5hBy24PUxp~61hoX@4Ez(1+<<+#b!p43p z8BdoPDYKhnsF1fTi;HMzYZKAFOY%b{=1pDjr_WytMKR6p?dJ8bS?k)$j!QJG(4eesX z6PgCmwT@dZ*IPU0OI~NFi|$)#Xivgd3$Em>_50=ErSy0;2miqUYVn7Zd;qA)nY?!`;cw*oY5aGy9sqo=jkm9DvOR~@huRbmO4pY=SL?N zwlDEmw1Z?K@tmh`_-q%W@>PGkOy7iu{a7RU|6maK?^q;UR|f|S^2I<3A38CgjnzfX zf=y_ziKMr;NV?DMXXX#(KT$lUf}Z179x*)wgM_|*`W)}X#6;RS@f5$B#Q(fyCqIW^ z5HS5JEvMQ({`u=MzhXxrBt*Qkv!gdsIQgGoS_f0Cv3Dw9V6ddPAMQy~@P8o84&)RH zJ@4z52KTcv`?W5O*tr82g6J;R?Rfs@$ewMJ`Sa%scXxNag=k*;ynz1$@jtfY5CR+y zjOA2GaOcO*7d7oG;w~<{|Hj7ZGc`d}2mZ$yPP=$=!?CHUDQz12>VIba##{F9%&VUPR2&MNw#8UcrRPQcZL zn4j+>uW%t_Q9vFL@KtZ2QV~QJX=(4-d{xxvo65?fel%`8Zh=$DKA0>fjtWD<9p7zg zEb)8Z8@H(wg>V0SR>kGyvW&~HbrAJA>4aeoY;W=39op5e{!a+-9@4SJHM+YLq@gX~ z_@v1H@85m=kKKMd3Yh0OaY4kxqhYn69a&VQ9TY@wzvLaCeX!`s_R`2G9SQY7=L~xm z?my?5XZY&Ju;>I$pdq4dr>PUM)wE2R+7a-+n+q4&*L&U$d2*gN8(*etE70QO8Ff9a zk>0<*k4spMjHhm_ud{5#dcKVFTeAvMA=gPtt_nP&Xp*Z%CZ7w#i2~^t@a`0}U4>sf zr}>@@My2|spG|$bp_Yh{kZ1Z&4w_j7`ysnk(j>T}$PZ0CLG1rrj95w39XeMv(Kb8` zr~3Prnr8z2^JgCdvBlqo^|GJXpDz?@+0-2P`#02ek&t!va3gVT`JlL^%xE#;(lv9a z`+25GKX%6mS}p2E4-62QnDHJQu{-5~`^djO*&AT}CtwK7DI3lH>A@YWhW~qp_U%zo z`L~v{Oa30L&l^tAGC0`G#B`#~%yBt4MN(#tSqBd#`CZ=c%u&1ftctH*$1p`aJfto@ z&nH``x>S)pJ=mg_mj}gS(+xoUI;1Q6m+e-9AJb+!$!rg1E6cQ)i^*L1NqUBcWIa6U zex8x|ZW1OTBhS`*Dn8rJc<#-aWBfODxLVz$oMW*kY$r3z&uBt_@rx&&dEWlFD|$ZB zTUY%X?uQRNBYOumkGB}3yh_5DsG)F4+`afdK3;p&yLh{eL$JmfQqYMpE^umQ&lKc}o?D z5U>_18IE(-a%HA(c_0*wZ-R+!kT%NT{*!`?M{*w?DeGBx4kSxtTOT%yAz#gpq37o} z%`f>65e33kzE@R+%NgB1y(uVQ{8XQifR%Wl#)u0G3p?BB>#bmI%>qRT?B8NyVoE!h z_ZAZt5y2$r=^t!VP>9C$y;s>IahYz?n_i+6)j#0m*R>D6UUNFM;zh(k{-Eiaqsq>& z%oK^w*0noPIA>LD(u)NmOUK3;m)Sr|hzpUyUjO6cRkQI#fx2~-=k-eH$#FY+y_cwn z2x$tRtxb2jimTm0WoVgw4#uXpH*S*P1o`LBZI5W&HQqNH z5^hfqKT8fj{sz;Sn7iQ3w2s^U9sEdX1l`W5Y;)P>w)ym zTNYMJs)4jQbWL5%pugN=Q1YP%(xJq57%gTrH;)Jd5dtwEzIU|sXFggr z(!igi(JX|4xbSH*4r{E{;)seu(bi}6Y?(v(XXemt4+ovr0_nkyWZ-1D{Zl{viL z?0&xEi=5GzgE>oJJ7BXDJ@5GfMy8J+8|?O{;j_DSJ&UgyksOAts*Im}L>wHVMs}c| zM5B5Jd6sXs*6fzNi>r^n_xj-*L`jMJAtoen%fET=+W#xRphunnjWnR$B3Pj`v`xVq zDZl8`_m7N$frP*%)I~Ct@Gq0NC>L&kU76@9l!{n50h0{Pc0@ltQveTFeb)32;rysn z@=XMJTf2x}x+=4>6JJ43uIP``(@av)`-Y)Ue949kY={tgDamIqBiR4Pm^PK)sB67< zRbsiMzRe!EJm5gvlQ=|K*%DRXR#x)vFBzbxDb{$5xZzT=4TnV&%Z2$gBBH6SC4c%j ztSc}=K`DV+S?3ycmY1EKT3uLeC2+K?Ty2a<^68C{CnsGvw} zgqWD=^o&2~JqDurB93mv+eQN3yn5_v^6`eZsoN<#YYGj8!XdaBbw!EisjaT`kEw>x zrHAdrHM#ISeIB#BpZNp>p-cBfTXCI-3632W$T*r-RT8lEj3w;{E@&LnY)~-Fwpj#K zyap-?ypKTms0|_=N1d{UnS_hW*aTdfqE@Bdea*{n-x#tTk!cmrJ5M+4hujhE?JelP zd0$yXKYe8wfs#Snv!u-FS!5n_VyTQa`WywPdhrdUFLD)z?y~siK`9~a#9B~L#P2c? zq>|Ghlaay0L=cGZIqt`9$|g!s`&as#L@-_tp3Cdr^Tz&1Zql&=noZ=nNxEs zbew(I#CyS^WV=f$3kUI3_$-o#0q_t%RokZU5Y^upPq%x@7m1h7!ayxGy_DtaiyK3pK{5MSHP;e``f}&!@^S6bfvVUuxnfjPS4Ba&~A=A)Wu$#y2{XoQ~yZyM@aaa-T z^yvqmEg7%P{PeDU{la0@k5c+%=KucbPnr_OuYRp0u9Ukk8a zM-c`Zi9NiC<@)9ac17Os*q${#J-gAi^2x>F&d%fUX@U?F=Vj*uDH=KNau23dVIAUH z_uXA`1aSm`2f9HB!KG~3-OafJfK=f&_0$1{lPe{J^m0F6&aMorvvakO^stVJ z#B~98vA1#G3l+75iB{jC*9UAamqm2s_f!n8qvNSNx7;9YWpK_MwInN!n-u5Yb(BvY zuIQic9mj3v5FCxN%pHR@P@2!3Ug&#qwAnP`l2P5wfzYdx;c&Ge*zn{tW@gyh`eq=N zp~$67oAmg2d!gc_SOc-V;(|qknftNc&WI-6*T-+${^|Y`GY&EZ!|T8fX`X<9q2hZ1 zXVls^!Eu(QGCh@3un=ZbQ()b}m32gDg}7w?{>ljOtz67d&R=&&EFcD5FuDlYtp>gP z^JlgFAobUcUW@F*^s!HT8P*%DP)WP_e9gJ#y}aNZ|LsM>(; zs@#|WdWnaNOF1Glb|FI|UAD`~t^pl=@5RY2~Z}&w5Kh5F1E4t;aq(r#7Hc_)* zF8%_s-pAdboThKXas2MtxHoPu@`ifErR+JZDl3)UJf#SUkdNZ2SHw(_8|0!ByhIT~ z6~87Xh8{IPEm{+&42Co`2p92J=udw0JZi*`aGXE=kw@KdcUV8Ncfp#mRPiacA}u!M zv>H@61QYu*McHku4#Fb58uU!5-#0_Y)x@Gm=NzwG>6t1FuMX?X3h{z`BO?a*oy=3W zP~wVGT{_gi8M!c5&#=#9Z*k4TOsZoshU888hF%Iu6@;IT&Wcaym`)d>=Nd3E^O ziaq>=zWq+(yf|fnEB{XIIZ1S=bt6E6o-a?pVNEFOMtS4wBelmU}{rukC-1=+%M|t zy5tFclG@v^hk(w6LZaY;0o&~)8RBS)5n?5XZ)l|rt^L>GsXI z0?dYj+NSU)nxA4q60m@`S!dRQ4EM;t(DSM7KjY$e^6y!fhbD8br^YPYuWVi(KvjhP z-C8a@S`qJ=DBtl*XUsij5J9@xt+kQ9v!+cRT)Eo0UKq}luU#Lv=f2AD_a_@#c@fx( zP+WCkABbql?q+wSvm%jJy55ei0)ix@g-e*^Z(6o`KQ+QrC(~$bIdYii2j6g`b;B<43G;rQVb`dh7~OOKOg=H{$6Hx6IDZyAcz)$?X+;-7Do z*tzQWoKy6^nFk)0?QLY)XVI;x)} zJVV|dQoCroQn#m#uR^t3V&&{SG`AZRR3W;^rJILg;aKta2Y8Hm?aBfICJmg`p7>k} z44j|RZz9+V3X74T`}c{MUwUImg?6aSOblE@#}-w}qCnaF^9V)s_KWUI6V92H z6-w*{+m&m3Y+9woy@sO|N-5n`eAZeTjM34O>V`v>U%BDBDl&3XxoT}je=_&ahB4h{ zOcP>@m#Wbb($FBwTsEowF2H|#$Mu?YXZV7e&hEO53?3d^I+PTTEvD_?FH%htd4pF{ zkF2j;9xz@mixz3~V3amL(t+Yu*u-d{m4&QJWz5Ff>$b!!he7 z@MeR^{?*mj($c@)hai&gv)z)YDE*qS&=cL-+he*B=6JeB1S5dmcOhw7K^R|jCBJ=o zI2yV^QFIZCs;$ktz0f4_Jrv*uxHbf-`N73J6wTQk)TP;?KeO8c+Cx!mwzI{5=H61V zC`>O&{IbaS<5M_8UO(lz`gI8Iw-a*eKle<2Isbx>0-|}0p_9$dZt|(-t!Ymsft{(b zJm?Q7Y)#j|rRe=*eW2Wpy#M`9VjGn&bH8GExok%Hde*WmRWy2?>+U^w-`(9({MB+G z3)vYVAKD3%W}S#wAe;*NrwT#kvbiwoWDk;F?&WJAYW=BK60GGjqas)5?QOyFTRdW| zdYv78syl8gr@2}1&B{Vl304FmW6;Rg2${}yNHJ9_|2(7lYihB?KZg#dQS7216zib` zXOKr|7Q;f^Iy?T_nAp}z3!dku#MM~f;@FgU0oF)bWU`9Q^0p*Imluf*33P;FLW^5qfw zMikkK6p7R)X|5QYp1ctnMShyPspeb?@3HRxjbU=QvNp)Yes{6}Q%+WpI}kB%jX?8m zghD_)QsT2Vc-7Lcqs?D7Ly}iqNl77oZ)$k5nloLNh2>ZFl>=1O9L8SH$>;-4LxU34 z1MkU!XL#Nj{JWG8zt3Z-GFcEqD;HiI3!bm7t#R&E=~Lr);665++bTJZZ+GQxS?dT)ki5#8Nobsb()G(Bi|VF7opQgb$BNAoH_ zJ}%Q=w*3d9w1`FphxkQ{|CTf3^M#kUGMG*lJzqV8RIgtLo}JY2vu$6j`mQiF{?JEa zHbX2zMa%QeBn@zLcUsPZXd~u1N+NKOLx{g=02hvFc{&HuHyl?hNPvSd*`y>=O1Ecqy?6;HI zmYjVIp=mdf-5|D6jm?Lo?VCm~(Kf$4Wv`o!LIQr}1Bcj`RJ(J`8ynBLc0 zqD514`%v1&bd7zDc~&-XLhZ%XA+6nVFpY}{wYs!*O95G3A-{ib2puu0a|Y4nu|Haf zNuz4i?uY)?#0v;Sq!gIBxPL*lE3)fyD7~R1)~c%&7LrY+#mJ~V;Ar>j&-eD;jeeCn zkIFN9Q#|r?6Cm)1*4hRfnN{;k6`&}4J9@UF}Hh#bglo3a7d7+K{ zF)nuL5x(hT3iDaV1nYC@vK+T&6uIPJ%`vT=&q;VG>4eDYaH&AKVi6xDS#dFp3q1R?VKN0#KEW~hhW*O z4FA>qp+LfyZ@yHcuD{dA@MPrsI|3^bx#cQLJ!&27CeSgVX18f>8`Y!n)-)7 z9?s$0U$AMfKeoL%A*}`VB+j>Q#nn$xsM>1PTt{M%^_)he^_+!FM*YL3-6*n4W2LW- z=&7W)>7H$YYvzLKM&rEo8yvD9NE9!aG{3jB=j4kWEQlE*@D>#X%;#(fG{WJ^H!FB~ z`yTSbIaIy;0>iS&WOwhztWiY2ANS~euEIb>R3a{rT}JjhE%vSr?z4F#Di?*WNRLGS zD_ITxICSa~X(TiWbV5I7wKek!mqld?1Pf{L;7AN4+#gN0!SV=pEW9>F!P>=Lmj{*8 zO^tYe{^&o$)}uaFvue=~cY87!DPm%6G9R|t?@wJ=geQu9b3+x*WY5{zM$aBjUEslX z9|%dNXNEfZh|SjfcE_d|vJXg`X5sB={%xQUw9=k+o3777+xz}4z1Ed4hQ$BO(Y51h z$|OBd6{4~B_3VVetrm*rsS@f;Z+%fi!ud6|wvS>{HfW71Oi6yA(;R|*JZ=12TUgXs zHnSf;ovn$!y+FM)dw9WKt|oFBBT$LF5LS6&H`#MB#)*(b)cx;^5F%o~xp>W~^9S>z zM^aHMaqoqLyizy~wg=0nT>#K3kzIsj<(~8@2>Z!gZxXkdGuvD}*4_$ug3Xv{>lG`i z?f2uyr1w!+Df!(L$HUz+9C~8witg=IFWoP##=46=d7TH(eJDtiEPf`AJ3WMUbZxpT@!m~ZEM z;unukEgsuykQP>T~owx~fV!b^JNW%yzAE|Uy=)0eW9*8`B z<^x%Ds#+>OM4w#V-!9m9lWH{zV)s|wBgZz6b6lzQV{%E}D->jp1oTO+u&sV#t0QU; zg|4!+Sp@^+?$M$(VMxS^5 zY8Z}VPr4Uu7akHHXO{72Z(UWkGZ6PRR=jTN&rTlOuKoZxdLYfyvHq&`=HK+@>gqTW zDlWP9EFe%cEcYspNKY<|p9FJ#;SdWjvHtly^!IaRH#A&)Yp%NeJw^zkdF-}*^yXkn zXf!cjmB+kIb-OutHX#3it<$7?>@rkueQsS5?~D~&Jx?^qrlp44T>UtWiqO;8kO@T% zzUqlT&ftUx*)Cdai}>r`=KzJOzbPE!(X?$ktns9_`&E58tj=#oN8g9G6ekG@W%p^| zYiQ_LqL|C^6(?KmF3dVlc)UQ0cuz(D<{JJRlhg4Py49Iu#_*M9)`$e0EsglB)d~f@ zPU8(<9dcF;au$0_2uohqBbOtwg;8fHe=xc|@)R|6Ds#tTLWw^*tp=yXyx~~#WeD^{ z=6yn$WZS~~!h+8Q-8hxh^7VSOXqKtKThcHfGm>BelkqC!XH8G07Ahuy@cQ$AU6rFUC>*&%v? zb1QaDF*`e#{)IaH$EdjfTg;%h!%zjamH_GzDMS&3EK`DQbhaRB^3F2DJq;0`yW*jn z`I9wl4AKQbr{qDGq(QXn+Xw?%8Y&C)N}cMDOXoXf^$es7sSAeUk4sN6x88T`+iS54 zA&7u6;tR->M!t`y;k z&S~UOfAsS;!Fey;aYXp%i6JIlyobk2zVo}eCA(X(r`Gs6n?Qxq?vqa$GS{T8Efof0 zqX5;wNUJ7d{(yz->+8!;(gH@X)umzF^_OJvnL<5kOnf0uuRuz67(TCS6dS=|+|ez* zxBC~;)X|WK9VUM&2@)sFa7JmG{5XD1znI3xrpy@tc8PzK?L ze+1V6Q()Cas&Dl>WowpRZ@h}A+PLJGK9Hw{3qhOsxY&SH^nnX$XJ_@TRDT~c0jCM# z>gwZj6j4z#2~qrnp{L6FMF8RzS;N6N{{2Jz#b=&L7N*WUzO)uV&=o8B$ePB(qn&g@ zrN`eUqo5cu(nBE9Ec(n0+}sgKV&tG$hJo-960**nM8K)w+wqgQt;d_2m`xgvDXgjlf{qbgvQ`Y)No@ax{p!dt{0Lu)$< zt4!qET|^aS!>&;B?}q2*_F;`_}& z!ly?8%xGAQ%__l^ckYk3C+Rc89Ip}>^kT{=v%DvuMgA2+)cbl=RJ;l}{Gpdl2+&A( zX2sOFwILzrnw?zbB0VAb^O}GE5MI2XU)kC55x~QARzkBJ!}>IQd<0c$h|0}OJLB${wn6#oF_w;K!>iw(sgHj&7 z?0cPQWtxt6Z8@<`2jyDmkb!h>B;R|=uLFv2-e=^$&1zk4CHncRmQ~`d^g{Qh9t*%F%shk7>e6!|=2irsw`A zNoS|A-Q9s41oCj}zIrjW#^LGGxH>_`P zF|gPm@A#6$;5uY_SU0UqA}b0Z4mKx#qb7VPR8W)*&cG8@4xbHy1a16iG5VCP$sCtN zvGK;N(3pC282_@+F0j=<4<9A=sv|r0*7%7HpVGYrUaNfF+r&f-kl~Zo?v`JAS?f~r zas1<5UdToq*-X=O55=6%DbNq8WNw$i)-k{G^M|BMxz{S56GV3UM26FKoVxyf0M(B`hqW$p#;KOk%{^d?Y|PM7M0e#ZeGld`kJHqk+1By z$D0#_(Bpna1#nt%n-a`=mkEKyAI*0*A0x9r4C3Pbz$DDKu(TmiDP3RL3e7_#Ge4QW zo}WJx+HxmVkZx3TC`VZG75m%SL=3bBp|Wc>*V)EP$sjR*t{%6%0b4zY1R_B309P{^1j~K@PNm}_Mzm10xVT=i5R{wj+t5B@; z-9y#F)^@3opcj>M58@D`@Es6Tx1A8~A3ZB80yh7ChIz(DwmE()@`x9HYafnfD;&Q7 z^n;V*W~SA_EbrWp(=+?iPJERrGt>l)QrVWjpKa#O=u*RGqu<%c{G&lhpyi1ktD9xo z`l{&vJNE^Jz(l~h8jA3QC}ha`rMai)X>aZ?OQ5eh{aJQUTR+&0$0i!V*32yDRzrt{ ztuyqy=KeHuXqz{F%s?t|z8_`x+AS|TCo3W%pty-_^9vmaoPM=s7!X5N#B+&_qh(&PI-e^iw0Di!?s-9+zAXg1b84Z=$j)K>vHGi=Ee^(97y6AnzJd^f-$LV;KWBYd^DJwfa8a5pR&P@ zR0OmeJVRIaZqEps$J7|m^#SJ6ZZh|JHPT~iWC&Q8vjFDVwhA=@^cYK$@It%l)?>@M zbb7i%RG-Tn1K^H9zlsJ-i4j6$%y{AW<{@9dyErR>-j7f?J1&8@QH8I*gT-=P%$EY% zn)mO$I6fyB#HL5_TYTlyD6uNY{LDTbpJM5!_^Bi4<*MZ|pmOEqr_q#@j0(>;J-vVa zye=WHRsTixYzCs8?J{H)6g{z|lrb zE$dcqMV;7h_w=CB(~DX1zR1A9-?kZ-RaN-x9do)HDEqU4?+!y!%2Qh~PG+tg1e||g zCIx_6mG7IMBIEW-zIYWqE=z!P17c1n{ut4km9xHyoMm*h_@BXz-CvpQsx2qH9lB8) z`;D0S(}e0-xYd(qf7p1k68b7hY{{G9U@_Z3OsV1YjjFpfh~Evul+rYG^-Z(vKKC|i z8rm4ddlT8Lozs6r34|su?2w&{M|5l?M)yi{cB_}-u3F&2JRjYAgcpXr^Ox%J5ld?k zfJ7m#7sKJ8l68)g|8I2&g5k!S6}F#U%}K(-kiyEh^)ll*+~{b=-BtYz#7we_&WY^J z**~SHV0;UU+Bld9}?N!X~Lgn4Kw9RZ#^!!|0szBmseUE33w9)mo`O295qReeACQcT5zqN zO>7$-@q6Gh%k=2S`&3y4W-t)I0srw@=?;$mgj{|B0lD2aweSQy$k+W4(RMp^@dp?;$~aOHRIzXnXDkPWNuA=Eqm~CBpMwT*r%^dUI^q z>A5EnQpy;1Xk6{XQ|g-VIdy`#o|of7p?u}#7G=hAq&78_f5+~|NP9L~{(~#DcrQey z*dWV%%%1%q;RwnrNSk8e%*?80Y+oPq@o^j_dz|g-gHGQ*oG8$IRabu~InfpEw}4g( z11CLak&s|0=mG`sNzAlq|18PmvTJ_h%^lp^?~q7*l7AMstFjgC5Vw z4g2vx-;>d{Z3mL!y1d~eb7nMtt>Z7XzSOtWV-Kr25Y|EGud3%a&x};s%KY`e6`;BhXMEKeT>Ysec z|2K6KTF$83^J&yo<(QAv7XGpS1+cti4hTUeNE49 zpUw7O^}%i{Z6z#XH$`R+gw7=X(TCHi&ttHL6)#(v>AJ&;n2j>fgC!9HDHYC>faVZ* z< z*$rxPvO=}DmtP*eQGV{mz#}>$8d5)x*rQfn;=f>!%j&ng-w2(mfqA-}hpYm)dY-eB2xWN}H>B zZBo7b<#0MfMtbo!9b2GDRzW|RdNts>06*^-TUM8CAN(%_wdMXs+$hV=w-uH`gmimK z={_~BV@lH>C}lfdB_f&rBqk!6t}H}r4~?9P;CJZo)6{1G6uO-$m1xtIQr*|KIUWDe zoJJ0hzk9PdQX%Gl-0Xi=@OJVorG`8VnD-2&<;VmE®w_`d`gV3yjY{|b6NDG+(F z+Dfp*;kmaQ( zgpwxhnx_R<$?z+(zcBOG)xj(O-onKv&u}*Y!5QxL?cP`t?_fsj3Ui*C1C%hkGmf%^ z$sYlM5zvGrsp|LslzMZq9neG{PhO9SWE6y`=nDqj z1!%~VaeKI+f{24Yh5YfiTrykv1_s2|_N4heH8s^wYtsen8*a~)!^|IO3%vpGm`S1{nVrYa5Y=)!`dfCh0Rn_j zm(8`DmU7cSLw9JQWpjCopTxDauI}8wxVyF3n_>Ml8_BFdMt#r0e~v37)8hNY#B3_$ zfiq(6_mhS~fUxGc4Uesct@)l)-)3G`xg!LX*ly=n;_61Ce%o{7)XTJ^xpdD%0pY88 zN1%RdaOcWZOpDk`_r^Qh929y|N=iX#IE}EoixKkU;>s85%vWuxvKDu*Wq)CRHfT+r zGsd%^_-41J$(cGl94Iq+59(F4XZ=7A0hE}QjKol{eFad^uSSB(p%@Qe|YfeXzUdkFO8W_f}7`qNU|fp^x<*l}Vf9 z+x02ZF!KF&Fc*A>P3K}`N6!dbQY%|?u*bB|Ug&g&f1a-@{yN-FhZW!F`(0)kyOOSB z^qwFm@QUH4{V{Onv#wIpE&b^DdN^PK5W*Kt=Ch=>ysY-QhX2llv}W;fB?rB-yu0EP z!NZ`?HO(u*do2H}?Vn1ryc+5MDIF%=Eqm|wt=`ej?-WTXO#&|2>5S}b*t}wRpL@)j z(>GHG35bU|Ug1ztpIgzuFOQy>l zZ<11~->-5khf1P!O3D!^VSpbBTM(z(Eg3Tut#Kydl|mLJ6|7d}8?C3syj)qg74JK1 zqvgZ=-$6!^ufNp&tRL@uyoS4;YObq7cMxFrU zy=`(ee)9{8O^Y-aD0ZEByyvqX2J_rCP`)Xl7=tPHpceiW#~_Mi2NgY5RGB@$`p=xo z`J@hit(U+6ol>0*-51L12quiX^RW>$^2N>1gd`q?-giNn5G1yO6h63@FIncUZ(wYj z7@}UW8L%>c(y1vk?KRjX-rWT%GF%^oy4kmEFwIY_1A6?<$ONJ!0QNE5Rij{6){+33 zr$QDC2C|Hdoa=`~Pa*)daLWfu1nRPl>NGdOUM;chr({kr0@elnxsL`&wEuEHk*SVl zmI8e>KffhjfzQpagDx~gMc+FXMm{U?)7eU-&m^o){;gTn7ESH5|9%xqNjVOSGU+*JN?!^@FQXL%yo@TU$)hH`Q zs~s^1%AqYXb{luqdc%Pp&49gR9VTAk=PqFSe)*uNT8qN@>`>y z!!$xH_uUC11dA9x~48ZFS z`0DB)!=iXv2~`1*Gp=>N3>n~XA=J4u7)Bd1ePBJn+b-COB zOAF9)ePUf*n*X_O@THk|H`sJ*F7-P*Ee}^Hnt63_l|*j$_C{nwCu@>%^eniSe+YP? zVNv_LWS0!c!9|17zndPaV9~`=(IH4^8iIv7xw*)=cmhh?(Uu*gdWqHR$=mxmU+WEDh<=CA(S=MtUcBI}$q(dspoKg__2F0wzUgL@8?t=7 zV&8x~8uHxV_^-y)iwhKvpify|Ny+w%Wby~mv%DL~#P&*fr2@aa3t5j9>zWKh0(w*M z0cb3<0bS0_{V)9N*Mb%h^RGM~E^=$xfhrUOd#v&yi;Rt5%WElG?5RlVeS(`g5V;s# z9SR=S!_*XYpg@|MN?bo!52-0bx|3fI!KnUDpV-n233?7ayH|(7E6Wmz2iIt$Q`U0` z4Hw^mV?#{$ZL++RN~0F4|17yu^r7t=Vz$d<%~42wBVW^XHWYB%5b*yd7QK&zPet9%Octy%~{j4aaLGWQ&Ab33uzBsp*D@t z;ff|UalgK+w`yM=(cIX8;W9&7n}e{MgeeOocrEV#+^YpCrV8YQVoCY_GEp`1ki--x){S~laCA$%ViX;?S7!J_$ zZDQ9+65(mndK-T12*LRn(zb8GZIUZK4(05V#b)J47ohds?SNMv&TO6y_p>{i@dgBxvwK}DGV3NqJ_`|hzicY*f4-toWyBP=#DhG`^_1(( zqJOUK(_*6yrn4~jA_53Gx4#NZ+#tFbL^T&;YTEW-)E>lh*XZ28fkq_<&+Uc+rxKJ| zau}ud?OPj=B1q9AZJHsfWgl8y?qf8Z$O@Ycqe+1J#kSEInQy^~V03g&S=n%R_t3dE z?B*=3+VQZ7*c|{W{X1i}#`Omz8CfPMe>Y#vg5&nY>nl zTYMj>zosAhn{X0B{%-kVyaGuHB5i zmo!D14NAFtI2+ zxFf<(WH5s2{ny15IOxE`BS8(j5di{x$m#u1@>(O;QR7vxV^C-{?DsU+Th&s15f!xr zhy*{NQ&_CR|dJ2w--ev$C&PANTG!2#n;bM z%myW%Fm)x-gDEk?A)YQVh`NJrOoNE!IBYwj1Me7*-lflkHB1B>e=d? zJOY?+_uk87q6Aq-RU;(ZOe5%VgwPVj!ik3junQg=P5YgMUcM1@ z-6dnUgT%b*f@q&jto)@R?|eX9&FGYg{sCKQ!SiM)L#}tG;==aLuQEbmf+`=M3pUX0 zgL?2NFI{Xl$*lMLqm>oMP%4AOyC|C_)O;NIx5S~M-cYvg`46v6IH55S0b}PoH5DK& zQ=xCQLn$7gC9*LxI@Ybl(l|UETuf=rVj8pXhez3!3JiuXv!@=(d@AJHTWS_VGe@UD zcU=x>8Z;Q`D^T{={n=_ZP0q2K6Klso^TM^%V2bVM1g~IoN}ON)R0-u)BwI%{i{}NF z4(;xvI+S3fZsqV-q7!j4&(^leavS`@NfcpA7-rp?{hD?utMtLZ@Gzc_Pu)iO-sM7A zBvV&sq^UwkNK_Q#*RN`>ySQw6TSLKn^R;;mj)=duhNZrI2`oq@5ibmW_bXtq%*ZZ@ zJxhiq3yP*UlVZF39TUNcixz;wNj&`x&K5G1l#~F=r(QkrO^WV3c)YK;CYuOA@V#y) zH{3WxYrb~V{lSY0u1efIBEDPNHy|ycfrpGnhO<;rRvCQI6JN)QW?(???Pa)kguc^w z_^SM4@aGLYwi0wS$1MkY`dx>2Gp=xuD%)Yu0mHD`MC=@?Dst>+{d>-}y};I>k%#OM zF;Gg=c{A#<4w}N}nm+=8jO8i>7QRLASoigxk-S3;UAu;AeAjSW4X1-_-y+J9iN!F* zibk}xhwAvWFTqFrDCflK?v_gX`a--KGx{%f>}$$hD>4uH;I_7==h?binmVe_Qq!h* z^$Nnu>cBNMBK&_9_MPEyebKu|?>)LO(Sm5vJHsfE5TZtn7NSQ&ln~t@TBIYo45B4O zH%b_Sh~7IfdWjbGzvuow-RHUG>zO(G?0xpyYrU(zhlQiAXw;@SQ+a*?|7~eV{7v}qdubVtvZOoa?Bd{ndDwe!0eQ!ch@8{y2L#knCEQ_T850aAfExCG-WWT~ z+(g!$3XPCeBS^iJcDiLhonQ^wo?s%8%1xPl2yyu~#L46lRtB7{KfM>jT7+J=0H zV7AeTEZZiMQ^fG7qIchpXV6)4)a6t-99VK#xE}9}6yH`fZ}7jFjcnkx^8zC;s&p3emI!it_H1c;GA3Lj=C|9ty1%gP zjBCXEt*&@6{3MkkMNWmG=LfL0NdCK~c6*M~#D+vf!^k8tEua)Y8=<$Kj0!)XLc-Tx z`(EdzRy?d;Vwz?}(jJP}n;26hctgWUE84~lh2W2{^p_KM_sHHq@Yu5eyM}t^HC>zr zx(SZ|OnQln!e}pr$S`c1N!WWxbVitt8-y}<; zqSr=h-B~z!={v2hZ@Ns%Ubp)c5Uxib079D)RV z$s&lUTB|S5iPBf5Qa5w3iE zIjFxzh?mbSsy4q#b$RT6d~wXPp_Qc7@uyc#(Hlk&8a$nhZfh{m0f3i4^}4Can}VY4 zefK-N^%atX1omTjSTnZLhnQqd0)zxAcw9;Lyh(24(eU6oTP!!N>ii&IZL8rsi>n58 zyXhh0_Y$vNV+lBubEKwD=ulePn!fS2kb?Hmp+j7a*08?3yjr_&A|DHM{8#o;nKMPe zV3gmJsme9GeaUH|$#)_6kAa$pyfxT8(wAx0A%EZQiVmoG#!yFm6R>FY+%P}RR3Ivz zXXZY3Oev>EH+&sxm; z0wE+?jpdZrX;(bvI-{5`_bG4A#%lPVtbVr450TM`Zocec9i!y@5|sPBK8Kqx-|#+w z|Ew@1%K8e20x#!{wGb6n&|Yi(Dl?O-)TTbp%qD=SIuAW((xu@~V<(psfeM=!G{mp0 ziDY?>T&Y0NBW-zOcJ~MGE}kT;zn5^*EgtCus`9wKy#*{~x3O-ET;n4pZJ#R5(tEEM z1MW2i<5d1w)zm3mwX@%!$21m{j9 zLtr*bZ6{o4AkWMot2Z3M4L2~L9VxYrk7c<2{r>sVuU{+y8!V+gA0k>ovTf^=vbSyB z5LP$$F~YbTLR> z2JB1S>^JQR54UHNdV20`%rvqG9c{HAMA~{6N@)q_RvOwjH{TF2^qKXujh zoYGEn7ii1`KCM$`(^&p=^2pDQRi(U-u-=4kx|L8v}joqoNh) zL0(k#k|WqAkW5}=YPR+9&nu){&qMj3q4Se#4&6-Y2ZvgK7%W#pq{Kt$4q_Tm5%^jr zCML3|JeRYwvg)yBRO4=Grec5K=2#`;5JH@Mve&(%>_d2nhet_^7?yIt$%+Zc$otyiZk_-)*WoonH$6EB z2-`3y6Fw`R661ix@XjDt<1efi2MJwVGWvL5@fTQSTfSI7~7u`w~-#dQ%Qt5Hd<4~PjH=i9KQCC5XJf+LHr6qyjM;06mHjV6= zV$AxrelTi_Io(EkeP01VHU_{0_M`)JF`d09k9lLQVu2An+hfP0feJF%~7!Fw*k!a&gP6 zfF}<|iXRsj*TcjCH4hFl`1$#5URX6kyB+KYc-%@HoHtCtzWBm{Ua@a!Y0+7QdIyBw zkS}&5XgqydIlcy1YQjn^s}~m9;|&Up!Qi!p;St#&#nXQME;pY9{fEhF9=8>JV$vK@ zqyu;f!*WW;FfC3+V)T0!IpD4IY)<+*z(Dv=hL7)0DJNYO{&$cxC@!X;rLu&n=iM_V z_&wD`wZHLbONhQ-**>0tu8OsSXkqEr($Q)JEA;C6o#q5k@~G+awYFFrafG9HnMeou ztc5>4Ew`a7czAW9FIyrW2hXd6Dd+>TIpjpICbSiF)VjTNOOBA}+WKPBW6$3(+^@Ke zpU40=1Cb<0r(Vw{r+x@F4*@o>)14zcd@g8-^vvD?2&DqqFTh&#?a6yNx+d+!EICo? z!jzQGlVbd(C?dKhoA+7>L+4Hw?8kbBAPK*20L$6SE|gC7^=J zq3*U@KpbYiGBPZ>|T|wp#rD>obwtk6v(N$q76)(%3n5U)9eFa_NmxRV{5^u zuWyZ7ROL+kXUGLBM4SAYaQ))E*NR7iv0ey?>aO5YDnJr|L*r zDrOEHC<~XTesyIGVUr~OM?x*d$_A+c#J^9Y`a|B!Yw5-1`T27)#8oCsAcx&wX(%JN zX;ib8_8*;#zPz3piTU}4ze+97Yb`a+IWho*48ZSEZ5t{K)9u0SX`yl>rcw@ z4Z)`nT+P>zuJl(1MJ88BsE}NZ2pW;&hwCe~w#kJ+2U6!uWBoW}Xl;&MGAaJ?cP5_6 z4nzx+C&pNWK@A^0upa~my=lKqO}Te#SH%BJNGAqmiAGs7B8EJMh)BW0aC#jaX2fU| zuy(}t;yz8s_|p0Lb#9oXn4^vay=Y>{;NW-CDqXle-lGeSv5$6r#2bxkzl>j12+j&aMaf?fBHny;`_#^Z3^0p zOBZz1J82OYQBYhn5r94Oi{3;TVt3!6o9$W&BSuY~oELwc96-%Q1hvI(#h~%D4VUh-X@d;?mq@>W+5+fjwnn?ecxFgklNg$^ z_S=(hN9(|32lixoRo=mEx0rcogBM!*xK`mN9e7PJfJXN%YG}_#OCow&;AJoQWtppI zgPEZRt7~x|2k!AkM!{1v%gjp82KWGKqex=BF<14FN@#Gvd$|H*5O~oLQX9{la(Xb@ zIaAA^LPDc%|ETct-*WfD-wjNn=IXz{H5K01B0sWK+|l%rh|^D3J0am}J|8xluktJD z-;TIx0)mdDRGRbiZNz9*O-$mo&CTkYJF}Nsea@e1S5^$VaYRnTU%6zd!QRHMD1Y+D zuYM~M@jVCs&FX5++#*5Ja(6%INoP7dJUZj>aN-L|lOl6MpA$pLosQm=WMTHrkPaic zab7_V&~GNJtf4U2lSvtHiE^quyDNwZgIOGLD_bpy2SEicNn+q#y-rso0b2~gJT@)H z64;`amb)Jxo%rf_xIb9grumS|6SufvU~NnY8bt%IJd<$`Jsrr`QxS7mH=P!H3J(od zgE+WCSnj#GUBPtZz!ccj^{57B0x5StFNW^Y*}L|=OkP(H#3v)&XZ!boeLuF{7qc2Zsi zXC#Lo=UMEWA3f&b#)k~ve27gGYmCg}yZt~lL@6Ek*$z6S?&oI~m3#9UFV1gMQjOTy zumtQ2d}(ah|LJl=C>bakPxKKd1OpbNUrd5tLR&lH=!;t|w)O$u3Hr3O1~SpRMJC$! zDItg9Is}36oUvRN80dX;+&dz%5GhsOjbvd1en&^Lb^QZLN2E;!P;`ia zSA4WmY`kSwWT(x|Zdd6cuJ;zu78M&l-{XDt z4p1rPYA?S2CMgOE`S)p5)Rr?8duJqp>Dl$iZcQhs6J(uIOs;1<`_bq6v)eG_ps4>; z;Z8b=f`H1jq_Vs^W^~ePl$o9oVEvbNL5Ij}JcyTxiKWuFc` zq@d8r)Vr;c68Dtu+I;W928W1w&8mRy1~etpQ*%$S2Du>20gkaOfc7{h z<(Mtd+Dd0A8K{kT(6ii)Jv~Be{8<{p{#{$JUji69EuMMtWeka^URrcL85!|*ehDfR z_@aTJ?F1ZPn$z9IwCANiTJb^PYau}I{)hg+K(BH9SgRRqaD9L7!NbTJ^obDf*AA** zK==gMC|#t!8@@Nr7N6kmUukDk$x;>f|KE__{5c_3RFJYRlJ_9)e{go!$&)V$evbwA8w- zmG<5Ew}f9T6(GVowBxNA)lC>nRZoS1NHz!j>3O(q8L&dV#m}pj z@tzb|DFO6Tvi9BG-!qLj-qKZ0@RwC@j1OYT-%weyQ2HherA$o7SeikAM@81Mz>d@~ zt)@2s=qp!Of>#Jp%;t;B`f)d4o@`!BA#T%DapDf%DeQ?)_1E^^E$O zrPu01S(mDss;7eK&OI(?x2*yBxO#YaySHuMTJrHPwV{f+ zmAYfOiM;@FA|U^a8u%slwZMQ_QIf&CK1e2P+u7l@gYKTI(&WDeKl1?L1j^fO;M-)X z;GiK99Hn~GZdgxEmKf21$o@^iRp8<}LiWFw#ZBOOxqZ1XvbP*+8V^j!OT4N&?}AgZpye1q&=$Khe-I|zw;0~CUjzpDwdFz&^RwIs~~Tw ziD@!t1bD{?1o0RNA+mQJgf_5DN)m>80kty{T{00Q@fgkPcjGVsHn37r0dWC-EOJF; zTr9VQkyFLJk_b_3I@*_)tg|n3A))mLYmR;x0n2J`_8COKYj`e?Q-R=svTs~ukF*1; z>lo^LdEuQQsjY;Td7<)C%+~Wz0iFxr`|7kH77$e}yP=gpuL|O+SCT~19yRsNR8gq= zR{7fuhK09H7n`+Hl~Hz$eI+uve;BM0j(C!_gQk90vM`igJ}NE z2FL6tu*-L3U&UEM>Fin6OEL;YMJSYCj7Ak$C!p&oMJ4h~iVb~Eq(aCj5hpQRaoa(q zR)wH{ z^n3uin$*Mu1lEZ-MwpGTi>Q$7STl6{Fz;ksr-nXgL@e1QN>a?~JcU;l8x){uaN|=aZsOKA!Xr=&M_~-3G|(=@>c$fuUlB0Nx#_L)dBV2K(LV8W_blN@@fVJ_p&b)x3flVFDI~)w`FB1 z$7>nP{`7mA$@uC<&uGJ-w&lji+FnSF(r3LgSdqoD=#%w(LUi-1&ZtpGAn ztD`_Kup2SDYuiG9eOVs;g833>)skAV!tA)$k z6K()EIg{BY)Tzt{f<{#@?^n;iMuZpj+}RDL$iK&7Rp|bk$Q~K|AgiY4RYiu<8;zK_ zqu1=LVlbmZ@uk$e-a*p}IP*3@!JGvw8ow_KInV)G!m$uMjq}tCN@{^Z7NrGdbn2S4L7i+}z$vohe#9SBJ;J zrw3ec-w4=ttFk~1yE-~K*&VD6Bi+mYqU3k3Ta$eAS=N1G7KXgTYg7mpzjdl|@5T+C zk}nq7T7P&_x+j&6b%aF{JiiQ&J2^RB6BO*48g^lFHo`_ are used to map isotope to hash values with which all possible isotopes can be described. - - :ref:`NXoptical_system_em`: - A base class to store for now qualitative and quantitative values of frequent interest - which are affected by the interplay of the components and state of an electron microscope. - Examples are the semiconvergence angle or the depth of field and depth of focus, the magnification, or the camera length. - - :ref:`NXpeak`: - A base class to describe peaks mathematically. - - :ref:`NXcircuit`: - A base class to describe a logical unit of at least one integrated circuit. - - -.. _EmAnalysisClasses-APP: - -We provide specific base classes which granularize frequently collected or analyzed quantities in specific application fields of electron microscopy to deal -with the situation that there are cases were logical connections between generated data artifacts mainly exist for the fact that the data artifacts were -collected during a workflow of electron microscopy research (e.g. taking measurements and then performing method-specific analyses generating new data and conclusions). -We see a value in granularizing out these pieces of information into own classes. In fact, one limitation of application definitions in NeXus, exactly as it applies for serialization -of information also more generally, is currently that they define a set of constraints on their graph of controlled concepts and terms. - -If we take for example diffraction experiments performed with an electron microscope, it is usually the case that (diffraction) patterns are collected in the session at the microscope. -However, all scientifically relevant conclusions are typically drawn later, i.e. through post-processing the collected diffraction (raw) data. These numerical and algorithmic steps -define computational workflows were data from an instance of an application definition such as NXem are used as input but many additional concepts, constraints, and assumptions -are applied without that these demand necessarily changes in the constraints on fields or groups of NXem. If we were to modify NXem for these cases, -NXem would combinatorially diverge as every different combination of required constraints demands having an own but almost similar application definition. -For this reason, method-specific base classes are used which granularize out how specific pieces of information are processed further to eventually enable their -storage (i.e. serialization) using NeXus. - -More consolidation through the use of NXsubentry classes should be considered in the future. For now we use an approach whereby base classes are combined to reuse vocabulary and a hierarchical organization of pieces of information with specific constraints which are relevant only for specific usage of such data by specific tools used by an eventually smaller circle of users. - - :ref:`NXem_method`, :ref:`NXem_ebsd`, :ref:`NXem_eds`, :ref:`NXem_eels`, :ref:`NXem_img`, :ref:`NXem_correlation`: - Base classes with method-specific details especially when it comes to reporting post-processed data within electron microscopy. - - :ref:`NXcrystal_structure`: - A base class to store crystalline phase/structure used for a simulation of diffraction pattern and comparison of these pattern against patterns to support indexing. - - :ref:`NXroi`: - A base class to granularize information collected and relevant for the characterization of a region-of-interest. diff --git a/manual/source/classes/applications/mpes-structure.rst b/manual/source/classes/applications/mpes-structure.rst deleted file mode 100644 index 9bc056b1f..000000000 --- a/manual/source/classes/applications/mpes-structure.rst +++ /dev/null @@ -1,42 +0,0 @@ -.. _Mpes-Structure-APP: - -======================================= -Photoemission & core-level spectroscopy -======================================= - -.. index:: - IntroductionMpes - MpesAppDef - MpesBC - MpesCommonBC - MpesExtendedBC - - -.. _IntroductionMpes-APP: - -Introduction -############ - -Set of data storage objects to describe multidimensional photoemission (MPES) experiments including x-ray photoelectron spectroscopy (XPS), ultraviolet photoelectron spectroscopy (UPS), -hard x-ray photoelectron spectroscopy (HAXPES), angle-resolved photoemission spectroscopy (ARPES), two-photon photoemission (2PPE) -and photoemission electron microscopy (PEEM). Also includes descriptors for advanced specializations, such as spin-resolution, time resolution, -near-ambient pressure conditions, dichroism etc. - -.. _MpesAppDef-APP: - -Application Definitions -####################### - -:ref:`NXmpes`: - A general application definition with minimalistic metadata requirements, apt to describe all photoemission experiments. - -:ref:`NXmpes_arpes`: - An application definition for angle-resolved photoemission spectroscopy (ARPES) experiments. - -:ref:`NXxps`: - An application definition for X-ray/ultraviolet photoelectron spectroscopy (XPS/UPS) measurements. - -:ref:`NXarpes`: - An application definition for angle-resolved photoemission spectroscopy (ARPES) experiments. This definition is a legacy - support for older NXarpes experiments. For newer experiments, the user is advised to use :ref:`NXmpes_arpes`:.” - diff --git a/manual/source/classes/applications/optical-spectroscopy-structure.rst b/manual/source/classes/applications/optical-spectroscopy-structure.rst deleted file mode 100644 index b9f5e11c1..000000000 --- a/manual/source/classes/applications/optical-spectroscopy-structure.rst +++ /dev/null @@ -1,199 +0,0 @@ -.. _Optical-Spectroscopy-Structure-APP: - -==================== -Optical Spectroscopy -==================== - -.. index:: - Ellipsometry - Raman - DispersiveMaterial - - -.. _Ellipsometry-APP: - -Ellipsometry -############ - -Ellipsometry is an optical characterization method to describe optical properties of interfaces and thickness of films. -The measurements are based on determining how the polarization state of light changes upon transmission and reflection. -Interpretation is based on Fresnel equations and numerical models of the optical properties of the materials. - -In the application definition, we provide a minimum set of description elements allowing for a reproducible recording of ellipsometry measurements. - -.. _Raman-APP: - -Raman -############ - -Raman spectroscopy is a characterization method to analyze vibrational properties for liquids, gases, or solids. -The measurements is based on the inelastic light scattering due to the material's vibrations. -Interpretation can be done based on peaks, which represent the phonon properties (intensity, center, width). - -The application definition contains a minimum of descriptive elements required to understand Raman spectroscopy measurements. - - -Application Definitions ------------------------ - - :ref:`NXoptical_spectroscopy`: - A generic application definition for spectroscopy measurements. This includes in particular ellipsometry and Raman spectroscopy measurements, but also other techniques such as photoluminescence, transmission, and reflection measurements. The requirements are: (i) an incident photon beam, (ii) a detector to measure scattered/emitted photons, and (iii) a sample. - - :ref:`NXellipsometry`: - An application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. - - :ref:`NXraman`: - An application definition for Raman spectroscopy measurements. - - -Base Classes ------------- - -This is the set of base classes for describing an optical experiment. - - :ref:`NXbeam_device` - Beam devices are used to relate a beam, which has always at least one origin - and at least one destination. - - By referencing the beam devices with each other, a beam path can be - constructed. This can be used for vizualization or beam propery modeling - along the beam path. - - :ref:`NXbeam` - Beam properties such as intensity, polarization, wavelength or direction. - - :ref:`NXdetector` - A detector for signal detection. - - :ref:`NXsource` - A light source such as laser, lamp or LED. - - :ref:`NXmonochromator` - A monochromator is often used to energetically disperse the scattered or emitted light. - - :ref:`NXlens_opt` - Description of an optical lens. - - :ref:`NXwaveplate` - A waveplate or retarder. - - :ref:`NXsensor` - Specify external parameters that have influenced the sample such as - varied parameters e.g. temperature, pressure, pH value, beam intensity, etc. - - - -.. _DispersiveMaterial-APP: - -Dispersive Material -################### - -A dispersive material is a description for the optical dispersion of materials. -This description may be used to store optical model data from an ellipsometric analysis -(or any other technique) or to build a database of optical constants for optical properties of materials. - -Application Definition ----------------------- - - :ref:`NXdispersive_material`: - An application definition to describe the dispersive properties of a material. - The material may be isotropic, uniaxial or biaxial. Hence, it may contain up - to three dispersive functions or tables. - - - -Base Classes ------------- - -There is a set of base classes for describing a dispersion. - - :ref:`NXdispersion` - This is an umbrella base class for a group of dispersion functions to describe the material. - For a simple dispersion it may contain only on NXdispersion_function or NXdispersion_table entry. - If it contains multiple entries the actual dispersion is the sum of all dispersion functions and tables. - This allows for, e.g. splitting real and imaginary parts and describing them seperately or - adding a dielectric background (e.g. Sellmeier model) to an oscillator model (e.g. Lorentz). - - :ref:`NXdispersion_function` - This dispersion is described by a function and its single and repeated parameter values. - It follows a formula of the form ``eps = eps_inf + sum[A * lambda ** 2 / (lambda ** 2 - B ** 2)]`` - (Sellmeier formula). See the formula grammar below for an ebnf grammar for this form. - - :ref:`NXdispersion_single_parameter` - This denotes a parameter which is used outside the summed part of a dispersion function, - e.g. ``eps_inf`` in the formula example above. - - :ref:`NXdispersion_repeated_parameter` - This denotes arrays of repeated parameters which are used to build a sum of parameter values, e.g. - ``A`` and ``B`` are repeated parameters in the formula above. - - :ref:`NXdispersion_table` - This describes a tabular dispersion where the dielectric function is an array versus wavelength or energy. - -Formula Grammar ---------------- - -Below you find a grammar to which the formula should adhere and which can be used to parse and -evaluate the dispersion function. The terms ``single_param_name`` and ``param_name`` should be -filled with the respective single and repeated params from the stored data. -The grammer is written in the `EBNF `_ dialect -of `Lark `_, which is a parsing toolkit for python. -It is easily translatable to general EBNF and other parser generator dialects. -`Here `_ is a reference implementation in Rust/Python with a -`grammar `_ -written in `lalrpop `_. - -.. code-block:: - - ?assignment: "eps" "=" kkr_expression -> eps - | "n" "=" kkr_expression -> n - - ?kkr_expression: expression - | "" "+" "1j" "*" term -> kkr_term - - ?expression: term - | expression "+" term -> add - | expression "-" term -> sub - - ?term: factor - | term "*" factor -> mul - | term "/" factor -> div - - ?factor: power - | power "**" power -> power - - - ?power: "(" expression ")" - | FUNC "(" expression ")" -> func - | "sum" "[" repeated_expression "]" -> sum_expr - | NAME -> single_param_name - | SIGNED_NUMBER -> number - | BUILTIN -> builtin - - ?repeated_expression: repeated_term - | repeated_expression "+" repeated_term -> add - | repeated_expression "-" repeated_term -> sub - - - ?repeated_term: repeated_factor - | repeated_term "*" repeated_factor -> mul - | repeated_term "/" repeated_factor -> div - - ?repeated_factor: repeated_power - | repeated_power "**" repeated_power -> power - - ?repeated_power: "(" repeated_expression ")" - | FUNC "(" repeated_expression ")" -> func - | SIGNED_NUMBER -> number - | NAME -> param_name - | BUILTIN -> builtin - - FUNC.1: "sin" | "cos" | "tan" | "sqrt" | "dawsn" | "ln" | "log" | "heaviside" - BUILTIN.1: "1j" | "pi" | "eps_0" | "hbar" | "h" | "c" - - %import common.CNAME -> NAME - %import common.SIGNED_NUMBER - %import common.WS_INLINE - - %ignore WS_INLINE - diff --git a/manual/source/classes/base_classes/apm-structure.rst b/manual/source/classes/base_classes/apm-structure.rst deleted file mode 100644 index 79f90e42b..000000000 --- a/manual/source/classes/base_classes/apm-structure.rst +++ /dev/null @@ -1,284 +0,0 @@ -.. _Apm-Structure-BC: - -===================== -Atom-probe tomography -===================== - -.. index:: - IntroductionApm - ApmAppDef - ApmBC - StatusQuoApm - ApmParaprobeAppDef - ApmGermanNfdi - -.. _IntroductionApm-BC: - -Introduction -############ - -Set of data schemas to describe the acquisition, i.e. measurement side, the extraction of hits from detector raw data, -steps to compute mass-to-charge state ratios from uncorrected time of flight data, the reconstruction, and the ranging, i.e. identification of peaks in the mass-to-charge-state ratio histogram to detect (molecular) ions. -The data schemas can be useful to generate data artifacts also for field-ion microscopy experiments. - -.. _ApmAppDef-BC: - -Application Definition -###################### - - :ref:`NXapm`: - A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes in a process called ranging. The structure of the schema has been designed to also document a simulation of an atom probe - experiment. Having a combined schema for the measurement and the simulation is beneficial to document that - there are many similarities between the measurement and a computer simulation of it. - -.. _ApmBC-BC: - -Base Classes -############ - -The following base classes are proposed to support modularizing the storage of pieces of information: - - :ref:`NXchamber`: - A base class to describe a component of the instrument which houses other components. - A chamber may offer a controlled atmosphere to execute an experiment and/or offer functionalities - for storing and loading specimens. - - :ref:`NXcoordinate_system_set`, :ref:`NXcoordinate_system`: - Base classes to describe different coordinate systems used and/or to be harmonized - or transformed into one another when interpreting the dataset. - - :ref:`NXion`: (about to become replaced by :ref:`NXatom_set`) - A base class to describe molecular ions with an adjustable number of atoms/isotopes building each ion. - For the usage in atom probe research the maximum number of atoms supported building a molecular ion - is currently set to a maximum of 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with - which all possible nuclides (stable, radioactive, or synthetically generated ones) can be described. - - :ref:`NXfabrication`: - A base class to bundle manufacturer/technology-partner-specific details about - a component or device of an instrument. - - :ref:`NXpeak`: (about to become complemented by NXpeak_fitting) - A base class to describe peaks mathematically to detail how peaks in - mass-to-charge-state ratio histograms (aka mass spectra) are defined and - labelled as iontypes. - - :ref:`NXpump`: - A base class to describe details about pump(s) used as components of an instrument. - - :ref:`NXpulser_apm`: - A base class to describe the high-voltage and/or laser pulsing capabilities. - - :ref:`NXreflectron`: - A base class to describe a kinetic-energy-sensitive filtering device - for time-of-flight (ToF) mass spectrometry. - - :ref:`NXstage_lab`: - A base class to describe the specimen fixture including the cryo-head. - Nowadays, stages of microscopes represent small-scale laboratory platforms. - Therefore, there is a need to define the characteristics of such stages in more detail, - especially in light of in-situ experiments. Many similarities exists between a stage - in an electron microscope and one in an atom probe instrument. Both offer fixture - functionalities and additional components for applying e.g. stimuli on the specimen. - -Microscopy experiments, not only taking into account those performed on commercial instruments, offer users to apply a set of -data processing steps. Some of them are frequently applied on-the-fly. For now we represent these steps with specifically named -instances of the :ref:`NXprocess` base class. - -Several base classes were defined to document processing of atom probe data with established algorithms: - - :ref:`NXapm_hit_finding`: - A base class to describe hit finding algorithm. - - :ref:`NXapm_volt_and_bowl`: - A base class to describe the voltage-and-bowl correction. - - :ref:`NXapm_charge_state_analysis`: - A base class to document the resolving of the charge_state. - - :ref:`NXapm_reconstruction`: - A base class to document the tomographic reconstruction algorithm. - - :ref:`NXapm_ranging`: - A base class to document the ranging process. - - :ref:`NXapm_msr`, :ref:`NXapm_sim`: - Respective base classes that serve as templates to compose the :ref:`NXapm` application definition from. - -These base classes are examples that substantiate that data processing steps are essential to transform atom probe measurements or simulations into knowledge. Therefore, these steps should be documented -to enable reproducible research, if possible even numerical reproducibility of the results, -and learn how pieces of information are connected. In what follows, an example is presented how an -open-source community software can be modified to use descriptions of these computational steps. - -A detailed inspection of spatial and other type of filters frequently used in analysis of atom probe -data revealed that it is better to define atom-probe-agnostic reusable concepts for filters: - - :ref:`NXspatial_filter`: - A base class proposing how a point cloud can be spatially filtered in a specific yet general manner. - This base class takes advantage of :ref:`NXcg_ellipsoid_set`, :ref:`NXcg_cylinder_set`, - and :ref:`NXcg_hexahedron_set` to cater for commonly used geometric primitives in atom probe. - The primitives are used for defining the shape and extent of a region of interest (ROI). - - :ref:`NXsubsampling_filter`: - A base class for a filter that can also be used for specifying how entries - like ions can be filtered via sub-sampling. - - :ref:`NXmatch_filter`: - A base class for a filter that can also be used for specifying how entries - like ions can be filtered based on their type or other descriptors like hit multiplicity. - -The respective research software here is the `paraprobe-toolbox `_ -The software is developed by `M. Kühbach et al. `_. -For atom probe research the proposal can also serve as a blue print how computational steps of other software -tool including commercial ones could be developed further to benefit from NeXus. - -.. _IntroductionApmParaprobe-BC: - -apmtools -######## - -The paraprobe-toolbox is an example of an open-source parallelized software for analyzing -point cloud data, for assessing meshes in 3D continuum space, and for studying the effects of -parameterization on descriptors of micro- and nanoscale structural features (crystal defects) -within materials when characterized and studied with atom probe. - -The need for a thorough documentation of the tools in not only the paraprobe-toolbox -was motivated by several needs: - -First, users of software would like to better understand and also be able to study for themselves -which individual parameters and settings for each tool exist and how configuring these -affects analyses quantitatively. This stresses the aspect how to improve documentation. - -Second, scientific software like paraprobe-toolbox implement numerical/algorithmical -(computational) workflows whereby data coming from multiple input sources -(like previous analysis results) are processed and carried through more involved analyses -within several steps inside the tool. The tool then creates output as files. This -provenance and workflow should be documented. - -Individual tools of paraprobe-toolbox are developed in C/C++ and/or Python. -Provenance tracking is useful as it is one component and requirement for making -workflows exactly numerically reproducible and thus to enable reproducibility (the "R" -of the FAIR principles of data stewardship). - -For tools of the paraprobe-toolbox each workflow step is a pair or triple of sub-steps: -1. The creation of a configuration file. -2. The actual analysis using the Python/or C/C++ tools. -3. The optional analyses/visualization of the results based on data in NeXus/HDF5 files generated by each tool. - -.. _StatusQuoApm-BC: - -What has been achieved so far? -############################## - -This proposal summarizes work of members of the FAIRmat project, which is part of the `German -National Research Data Infrastructure `_. The here detailed -proposal documents how all tools of the paraprobe-toolbox were modified to generate -only well-defined configuration files as accepted input and yield specifically formatted output -files according to the following NeXus application definitions. - -Data and metadata between the tools are exchanged with NeXus/HDF5 files. This means that data -inside HDF5 binary containers are named, formatted, and hierarchically structured according -to application definitions. - -For example the application definition NXapm_paraprobe_config_surfacer specifies -how a configuration file for the paraprobe-surfacer tool should be formatted -and which parameters it contains including optionality and cardinality constraints. - -Thereby, each config file uses a controlled vocabulary of terms. Furthermore, -the config files store a SHA256 checksum for each input file. This implements a full -provenance tracking on the input files along the workflow. - -As an example, a user may first range their reconstruction and then compute spatial -correlation functions. The config file for the ranging tool stores the files -which hold the reconstructed ion position and ranging definitions. -The ranging tool generates a results file with the labels of each molecular ion. -This results file is formatted according to the tool-specific `results` -application definition. The generated results file and the reconstruction is -imported by the spatial statistics tool which again keeps track of all files -and reports its results in a spatial statistics tool results file. - -This design makes it possible to rigorously trace which numerical results were achieved -with specific inputs and settings using specifically-versioned tools. Noteworthy -this includes Y-junction on a graph which is where multiple input sources are -combined to generate new results. - -We are convinced that defining, documenting, using, and sharing application definitions -is useful and future-proof strategy for software development and data analyses as it enables -automated provenance tracking which happens silently in the background. - -Base classes have been defined to group common pieces of information for each tool of the -toolbox. For each tool we define a pair of base classes. One for the configuration (input) side -and one for the results (output) side: - - :ref:`NXapm_paraprobe_tool_config`, :ref:`NXapm_paraprobe_tool_results`, :ref:`NXapm_paraprobe_tool_common`: - Configuration, results, and common parts respectively useful for the application definitions for tools of the paraprobe-toolbox. - -.. _ApmParaprobeAppDef-BC: - -Application Definitions -####################### - -NXapm_paraprobe application definitions are in fact pairs of application definitions. -One for the configuration (input) side and one for the results (output) side. For each -tool one such pair is proposed: - - :ref:`NXapm_paraprobe_transcoder_config`, :ref:`NXapm_paraprobe_transcoder_results`: - Configuration and the results respectively of the paraprobe-transcoder tool. - Load POS, ePOS, APSuite APT, RRNG, RNG, and NeXus NXapm files. - Store reconstructed positions, ions, and charge states. - - :ref:`NXapm_paraprobe_ranger_config`, :ref:`NXapm_paraprobe_ranger_results`: - Configuration and results respectively of the paraprobe-ranger tool. - Apply ranging definitions and explore possible molecular ions. - Store applied ranging definitions and combinatorial analyses of possible iontypes. - - :ref:`NXapm_paraprobe_selector_config`, :ref:`NXapm_paraprobe_selector_results`: - Configuration and results respectively of the paraprobe-selector tool. - Defining complex spatial regions-of-interest to filter reconstructed datasets. - Store which points are inside or on the boundary of complex spatial regions-of-interest. - - :ref:`NXapm_paraprobe_surfacer_config`, :ref:`NXapm_paraprobe_surfacer_results`: - Configuration and results respectively of the paraprobe-surfacer tool. - Create a model for the edge of a point cloud via convex hulls, alpha shapes, or alpha-wrappings. - Store triangulated surface meshes of models for the edge of a dataset. - - :ref:`NXapm_paraprobe_distancer_config`, :ref:`NXapm_paraprobe_distancer_results`: - Configuration and results respectively of the paraprobe-distancer tool. - Compute and store analytical distances between ions to a set of triangles. - - :ref:`NXapm_paraprobe_tessellator_config`, :ref:`NXapm_paraprobe_tessellator_results`: - Configuration and results respectively of the paraprobe-tessellator tool. - Compute and store Voronoi cells and properties of these for all ions in a dataset. - - :ref:`NXapm_paraprobe_spatstat_config`, :ref:`NXapm_paraprobe_spatstat_results`: - Configuration and results respectively of the paraprobe-spatstat tool. - Compute spatial statistics on the entire or selected regions of the reconstructed dataset. - - :ref:`NXapm_paraprobe_clusterer_config`, :ref:`NXapm_paraprobe_clusterer_results`: - Configuration and results resepctively of the paraprobe-clusterer tool. - Compute cluster analyses with established machine learning algorithms using CPU or GPUs. - - :ref:`NXapm_paraprobe_nanochem_config`, :ref:`NXapm_paraprobe_nanochem_results`: - Configuration and results resepctively of the paraprobe-nanochem tool. - Compute delocalization, iso-surfaces, analyze 3D objects, composition profiles, and mesh interfaces. - - :ref:`NXapm_paraprobe_intersector_config`, :ref:`NXapm_paraprobe_intersector_results`: - Configuration and results resepctively of the paraprobe-intersector tool. - Analyze volumetric intersections and proximity of 3D objects discretized as triangulated surface meshes - in continuum space to study the effect the parameterization of surface extraction algorithms on the resulting shape, - spatial arrangement, and colocation of 3D objects via graph-based techniques. - -.. _ApmGermanNfdi-BC: - -Joint work German NFDI consortia NFDI-MatWerk and FAIRmat -####################################################################### - -Members of the NFDI-MatWerk and the FAIRmat consortium of the German National Research Data Infrastructure -are working together within the Infrastructure Use Case IUC09 of the NFDI-MatWerk project to work on examples -how software tools in both consortia become better documented and interoperable to use. Within this project, -we have also added the `CompositionSpace tool that has been developed at the Max-Planck-Institut für Eisenforschung -GmbH in Düsseldorf `_ by A. Saxena et al. - -Specifically, within the IUC09 we refactored the code base behind the publication `A. Saxena et al. `_ to better document its configuration, here as an example implemented like for the above-mentioned paraprobe-toolbox using NeXus: - - :ref:`NXapm_compositionspace_config`, :ref:`NXapm_compositionspace_results`: - Configuration and the results respectively of the CompositionSpace tool. diff --git a/manual/source/classes/base_classes/container/ComplexContainerBeampath.png b/manual/source/classes/base_classes/container/ComplexContainerBeampath.png deleted file mode 100644 index 597cee834c0426bd0e60b1afbf6554a5f3b04a99..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 7089 zcmbVxgT!j8lW(I7CP9R3l4E<2>J5 z)AI_IpP{<#g$8#av2ACx&qHz?7*6{wc9+~vb1nw=8zsvCGZ@1U!ma35{YCTeb^go#}G;SGXdmMbu z&k(dLz+>M0rk*>Sf)`6r0rqXS-WdWA6B8%4ZJE%EdqQPyjwzkRB;aOHTl>4)o5x|d zk^nCj4;eIl%(n^F+aGp�Z2d70QK#NZGhGGt4!*DVv+aK@%#_`tEYYN5riu(%l4#$J*D7^Wj?wMl{e?}qh~ zY>s%K&(C)zD>TXgDhM0}O&=C2r+yy#K3pp3G_SZgw*E;r78oa{=-eoZRr2X4M1X%T zpwKhuUnefLT1P?+p*cUDbF;27;urNXIdV3GP9r`-Tm1Iz!5axr2q&_2aKHv)6R*sV zoC86Z4ZQcMBBg7vGph*EBH-3c92|H`VKT=wJcAF`QUTL~RppiMF@&7l+%|jh=q_Yl zl(4Ai%5;s*CbbwAZH2$YiG@Y5cQ^ujWfjnl_}!#bRb1n>F}OTlrVE!&9&uFk^!!4^ z;FHzbDye5^Xk#UxwXh=zxB3+h)q$p^rRmjVynV~|G~Rjyp=(MM0mu_vg>= zxp&taB#b47RTc~^Sn`WBaGB9RJ~<@SMf)iaypK+F>MgC7zsG<%r}Pqabh%S?=ZlnO z^3i`NU#PHfxzukcD5suN`yh?Xm0-C9poTO!`bZon&_&qD+`{Bx!n8>beH987Qkx%6 zRNOt{;*|T%y-h7HKpqjqJ|6|a$DY4jlDeCYdZAn2&+t{t*H<)>RWW_m=_B!yXoyoi~j%|VXyXk z04CaDLB0Woc^Km9>6tgSGvc<^MsnrPilHHjLv>{cIk;b)x=dF3^O!*;WI(#z7`=S_P(B*fsh&^#>LCqbFwo<4%S1-m5+rtCdO_86H82|ZC-J$ z^0QbYQ`^F#vI*`-R!K??acY7!^%XsR4*+eK%Hj)EVh@1o1ZacHTr3XZeXE%-cJZ^~ z?igTnbhO%Wgc-Tl^we?eguId(P0owu>bd@t3XpYIWGuOgQ3;QMy?OJ-3M_sY35mfq zuL>o*x~!TS!N0WzGR3%G{DKF@zLYPS60_t>W-)`#e=IG9h1bEVcPafZw@P#@ERv6p zy`y8B4KrpKCaWw_2M6wwSG%=MfhV6$c;?N^>W7f6Z-J zDZ9VEuFcES$qeV@;ra2!?iU#qRgB+afU-yn!0$B5%45;`0FQ+Jpvg1>NBLMTz?jA| z)(osl*JpZq(Vf!EzRs{Z#ZpRbFK?ztkBILl;4p?=3tZpa=+|-|^w7C6v9sgywH;Fs z5D@4!^2MZlIShqt{M-5$5}9@b3BTNuH88kO!XO#foj}bZFw%z41MhYee!kk11Oklz z`dh>Fa}3e4#Q&K^U0w$2y?M`4s?}sm*A~AeYh%N5dpXtdeQ1dE*Lyz0`5f+^M4G6z zHCqtGR@VAntA~)o{%h9k?(R;MI#dUbIHEcyL@Z3EPxQq*VzL9^&^mv_@!);Obxb`s0N9NAtehd-L8uV}6C42C7z=Ib>PI6$H_DA_up%NN{Fh^> z@6}Hj#FD_{!Tfx_zu5NJ|A5Ka53{$5E!*l!AM|fiPAus(m+^;m79F8dyynf(?=1rH zL1Z)>HwZHN>dAH-*ru$A9m`(xn;An7#+IpHMW`trs;7o`dodKo%*qNKlD;Z0@SS}M zHU)v8)BotDgVO^R+R17TGolBVnK8I7s(9m@l)VE3NI5x(eSbQnP-m9fpg%(h52&{L zb-y_Dz`Ik#*O}nHg zNlM)8!9#x}(&v1I@WQ?csp#Kj<(@;5C9WOi9N+_lr(szFV>MwNGCcRs0*lZ|JIVP9 zA=!WCs+T1Mg;0=m61V*fl8wT){%kq|Mn?2fwDZ(fo$MHgwK`?lUyM`_1(0Ukfxp`(RR^z-IUr-0Hi-PWow{Cu;JB3(UcuYs*w zS4*6aR_LvhhkwGVo|nTL3j)wU85OH)F@&*_VhEf6T494$f9%^o{wW)R-E2MjvGeza zFSC{4jJ5&0C5fpaM@X8+x{0vKT$s9P6dx_!2}!7${-?<)v7eVYfycvLXmo&twy8~2 zSzgxcRWV?%+mDKmCxGJOHY}zf zBEzVtsQQD4x4pr}DhW>kTOQr`_F+|Id_uJWpE4krDs1n$j^ z4~#^#*Vo<6%_-@S^o6&xx9o;ptbyqcres_rlnA$?e4mR+7B4CynP7Ygfwge$eLz}V zGHzyvt(_DOG`TG4bC_tSFx*_?tgdwH@@G^c9{#)#bZ|j__6fymYZZ3A(t^oZFRLDJ z<|7pqNdZ|D!)U?g&d%b-{%;MSR7p(6^ymT)h)QkekSh-{N&J1hTjn*>H)-(^OFEn3 zfYf#FlAvDXSZH;}`L!fzojkUZ-u6h1~<|ldl38{cs(Tz z^yf0hlCvn;jF)zoekSZnWBb{^yuUDabL6)Zuf3|k>+R2D zMvZ^Gh-lu&y-J9rKP7y=AV`reWqLvN9_W;5A}8f@GEIFJ>MP(|aY1j>ljymVg<{x4 zjTFww#AKCVyAHqe?wr(PU0Yvgn<*~*(cO)Zkf1efbUo?C5fXKog#!N9hvflQ_Ei@1S=cn*o&~0NkFVWeV!*?(Mf@_YaIXRWBoSN8N{9R{?_E)?I0Pl)- zSk3-lc6VCwGx2l6)(wj|_KY$|AtH*hpC?w_!mj9Eym)c1V@Ac9UMldOv9Ym=hDLYW znZ#o0TO2BlDK1H~Tb&O}SYUmu{fUFUp;BFPRH*QlWfB*sA(cD;7K8SsKm<0T%Jh2< zl25-sW)G5-%1!FyUy%-yRq84#LT$7pDM1{kASaKA|J*&W{>_j1Bet3!Q3ERr3${`r zxt8<=t9tQd$(x@834HBwAge03Xrmn&8TmB#UY;zXJtTXHv-mT3HX4_wdxXvk*q_u~ zB^KOt1>j_xQ&o(Mfjf`PTK&m~q|UNl_(H6f+C%*J+s^o{zeB+URn(uW&@u3)lKb|J z;p;&>2N*w%=;1HNUykTZO0!8|{kbxXs;a8Jy}g~u@F#jT#yUC?U%fU8K$QTFg)4oE z%_J{+UxjhaAyD}a+Cs@wwyCv08}-sKhMprLBO|M=zF~n3htt&!q@|o7$!ghePmm7z z=+^r^QYn-8Z8ux1OeYQ)J;h$WBE@i|1QQu8Z9J*;IbdgJ7r&Ia))|34-QYs^?AbGZ z=Sd!<%U1ubM*O7q$3I697l{b1@r}c zb#YGrIZ^e>4+;7>IyR=G?@1{o-#w>byhE2awIfv-SjnB5>qWm1bS$f`p7=skW1XFT zab*!&nTEAa*pl^45h`few>x}ywmtEbT}whUI9L)~CN=kUf=-|A2g^ng;RDWaM3N{S zftMEMw&v9*0uNO={Kbrmkq%3Z5NXTI?3koyUB@P}H98^f}=x3TKl?q2}O2mR_|A|nL zG%`hFHXWWohRc4KLB~t}UJ|dtfA+lL(mfBsorQsVS4B-NvMQG`*|mrnY;qfg*hFN{ zAVt)=7mvOnW!V#zSZ;&1_0}9V3d%PhmV*IWUO1bT7+5{`@uWt=L$Aen^UF!p7wjLOt42~RsEI<~v438pG3D_0z4+^UFEz|`) zvuD@Lii^O;!@>~8S9gxNMoiLx4hhjF6<`Q53Q7mdctdkR2MJQ(Hb3194@9I}(Z6jDB zJ-!i-Y^d~bBcC&hzN{R&7{>TGfa3hb5Hl;n^pGGf31?*`JccmBb>U5|n<%zhE5z0o zFs#D*K1$Z!-dX3=Ia(A>%e}X|NL+4)pCwH^KJlswMT6a+iTAMxVxlBhGDD=E4w!Xl zR`oTwY|rFK!#R0fgRZJNaIvu794Qm5yb=~B`#Y=?lD|D9mB+$H zGGJ}T z>oxbA*&q6uHWjLhk7x@@K%-tEY!@WtNf=nyYKLH|PiyahN^|b2kcg7p`!3!)O1;1M zD8B@WA@E4Zz66RO5QvrA8XNqw&$>ONTwlKIRz-bacHh*#f`TAOsjnZcp1tkwDX9tt zZ{qN8LFksZFmv_H?%aH{-5m}-3H#ct$VIS<=6#fu9l;H<{q^2lw`hBNw4T9Fhg>pw z-#_9?|jjKcL2)~hIOYm38(_cRw(@DuF$S@N9u3V*z!Az)-2&b_hHdUq^ z3xAG=x_$BS|6XF^xpYf4D&8f*`ZGCZZ*GH5cAFtri0_{bBW7wN&i!X;U;vBKFoUaB z6dC4ff2%rVim5w%$osJCH6|G^oQf{XGA&-h3Vz9;(IbvVh*_!@a$6 zyTloD+(iBw#EpzJ3i{pq)k`)&d?7g=D>&G!kx|lUUOLEtfpK)Sl+m;S2)lf}(;y}2HdDyC+iQAu1*gEi}#v~#)tauKr>f77x zt6>sJhdB3RN6g7o#Nn!O5c2@$o2<(txGSh4PEM)$;^+L99-&Aj;AE5vj1>sQN8#5B zF>QemN{)ubKP~$|T#CZT>1e}^Yd5Ps9XV5SNamaJ%QYO<)?X+s!HDn+>w zgkDCoQRbQqMq)6TbMKLEM=HzKk<4|35{?o}k|!F4XAzn)`Jp=2rzD#7Y<@KZ9_6xr z9pG^flGkOg=6S@9K%*$XI8h=F4-3p?WM;QM;o1v@ECrnoCksU7yJVMox*z0C<2SkI zpI;8id|nc0`Y*%L>%eNNE3z$!^6!M<_Bk7b8p6h(>7>O`A0 z<+Zv*G%oobe{*ED{dM1NZ?PGvV#``j4cAc7NNPgGz!Dkv{TaS@;b(}yo^=0#PGFJz zZnL536YPaW4f$FI*7aZ8k+WfKpLp58WA|%}Q@wZTZb|N&MlBd(NM`?fsxmB0elg5a zyhTfzYtn^Y>O}{*Xk9rgF>z5nn_pVy(}ezLUu)}VJ-yP^B{+!VuV+ohkm{K0X1(jcKbDH?b&>a_(vxDPrweFG!4ZAQaM@IzzoNjj}rA zDd{kJNtN8Ib6~C!yRUCI`0r^kQiz=V_+lWl4sGU=mKMH|Lz&xg`au%S7JWZM-(ZyC zY#>w0b+bZ4{R69Ou8h`8GW{N}ZKwn{hbDlMWY(nFn;@L7Cww3hUttM6+E&%TSqy$H zO&vQlZoeprsc76h-5UFw_||P67JNj!psA8~0(<040j;#8ZhWd1PAZ)@XY#1pN)8>I z64k46S?F;kD#aHQ)0rptsTt&LEW5MFr}iV=DwtlH#MuJc^?~}{NW{(*GKiKKp`5JJSn=tL zWw`ym#rh3c5D}+>zU7-!QKX}9Q^r3wOy16eEhKnz|J>v1gl6sbZ`IcmKef_PdcMtKNSG<9Xx4}|=|E$9hEynSWZfFpV5_G*B%drKT zf{p37pZB$gbas&@46(47YZbb@8iCPEJw!2f+^TU{;OoX*ofcVd4Ci}K&W{udOOZ=t z#S%e0z1B4hVGwq$;tgot*W3B8oi}G=XMrnFctcBY#-FJdPMc3$vx24TVrm__`JV{r zWa$;L>gx-iP}rwlo)7P^BtBUGJ-T&NRCFAm0y}ZW$gYQY;R;z9O3Hq_ZqLg}D}5gC-$dChBeP#=_&Wpc z6)^{U=SlU}^T*LAGHTrz*Ap~tFkB5b#KBBH*19n!!Q|!N93nX5?j!e>NF|R`ZpIhF zfmx@Ej=QHU&3KG@J$PDno7xgmx2veFAUE;jl8Mo>b>~UIVQ`vsRSAk>_BorqYgesWGUr@`D=W&OA`>A)AQ05o^3v}i5Lh$_1g0Db0lX8X^R58= zdf_PfS`7(&c_EpEf#a8U@*f-_5PbCK9~ip&QWWqep_7c3ld7$mldF+~Da6&)mG!fY zrK7QtohhrW!>5!(VIl~G0`gi~Ld`98f5FvDO??sJ_>&oD^1wR}x|gq!KA*>kW5EVw zuUbm{adpZ^)|#v<)Y9k-VZzhDP{*;_)>cuIo~8+KLbAq6P{#TvKm7Nd=TnVILXyxI zl%HESKB7158}lhreFI-Shi*ud+gI%T>QLF(*pdb}OAZlKLK#?DW!>D|G+hJ3hT`Qk zUH!BpqoSlOEG)n~d3pyk6^H@?0(uLmRDw!Sw1tuBKgK6BpE8`C`NC!=5?;L}APMt; zaR+}E78d4#hJZ*#MU@cM>JN@+jO{4EQ73XtfufD`t#80g8K5T(wmmSFzPQ|niIO#% zUOgN34?|k1wVv~&`)qK;1#&U|SUpzI;H)JFc+BQ?Po4OrOMFz>WFf8o z9?c@2ej~~&m*e?<85w(3)Uwse+1)OJ5mUdcTO9zA|L5vGqJP89V4Q zLZPB^_-L2eM9r>zZP#fA*Ywo1dUUg(N4JSGKmb1D~NPY=dncQ+j0(tM>i z71eHtTc`hR$-q0qBmFFo^&dP6g{;}xe&oJ58oC&mDk$LbTt#kZ%08?1cO#%9_&ha! z=6r>TS=o|>yj!oBigB55F8cCxgpz^-)9q%XWDg%xg|BN_+0eZBF}=T!_U223F&dv=VeyWm~`2Y7bj>l_ksTBB;}*4 z>ovbvbPPNMuVab10~F*RHt0m-_7C7u{h#Nam|r;$`Vz9_J>_!8qVvNhmTZCJc^C9eHBn(jF{TXU6 z?l($^k2k|5du(8~I>BrOzJGatj(yyL-BO_5hBy24PUxp~61hoX@4Ez(1+<<+#b!p43p z8BdoPDYKhnsF1fTi;HMzYZKAFOY%b{=1pDjr_WytMKR6p?dJ8bS?k)$j!QJG(4eesX z6PgCmwT@dZ*IPU0OI~NFi|$)#Xivgd3$Em>_50=ErSy0;2miqUYVn7Zd;qA)nY?!`;cw*oY5aGy9sqo=jkm9DvOR~@huRbmO4pY=SL?N zwlDEmw1Z?K@tmh`_-q%W@>PGkOy7iu{a7RU|6maK?^q;UR|f|S^2I<3A38CgjnzfX zf=y_ziKMr;NV?DMXXX#(KT$lUf}Z179x*)wgM_|*`W)}X#6;RS@f5$B#Q(fyCqIW^ z5HS5JEvMQ({`u=MzhXxrBt*Qkv!gdsIQgGoS_f0Cv3Dw9V6ddPAMQy~@P8o84&)RH zJ@4z52KTcv`?W5O*tr82g6J;R?Rfs@$ewMJ`Sa%scXxNag=k*;ynz1$@jtfY5CR+y zjOA2GaOcO*7d7oG;w~<{|Hj7ZGc`d}2mZ$yPP=$=!?CHUDQz12>VIba##{F9%&VUPR2&MNw#8UcrRPQcZL zn4j+>uW%t_Q9vFL@KtZ2QV~QJX=(4-d{xxvo65?fel%`8Zh=$DKA0>fjtWD<9p7zg zEb)8Z8@H(wg>V0SR>kGyvW&~HbrAJA>4aeoY;W=39op5e{!a+-9@4SJHM+YLq@gX~ z_@v1H@85m=kKKMd3Yh0OaY4kxqhYn69a&VQ9TY@wzvLaCeX!`s_R`2G9SQY7=L~xm z?my?5XZY&Ju;>I$pdq4dr>PUM)wE2R+7a-+n+q4&*L&U$d2*gN8(*etE70QO8Ff9a zk>0<*k4spMjHhm_ud{5#dcKVFTeAvMA=gPtt_nP&Xp*Z%CZ7w#i2~^t@a`0}U4>sf zr}>@@My2|spG|$bp_Yh{kZ1Z&4w_j7`ysnk(j>T}$PZ0CLG1rrj95w39XeMv(Kb8` zr~3Prnr8z2^JgCdvBlqo^|GJXpDz?@+0-2P`#02ek&t!va3gVT`JlL^%xE#;(lv9a z`+25GKX%6mS}p2E4-62QnDHJQu{-5~`^djO*&AT}CtwK7DI3lH>A@YWhW~qp_U%zo z`L~v{Oa30L&l^tAGC0`G#B`#~%yBt4MN(#tSqBd#`CZ=c%u&1ftctH*$1p`aJfto@ z&nH``x>S)pJ=mg_mj}gS(+xoUI;1Q6m+e-9AJb+!$!rg1E6cQ)i^*L1NqUBcWIa6U zex8x|ZW1OTBhS`*Dn8rJc<#-aWBfODxLVz$oMW*kY$r3z&uBt_@rx&&dEWlFD|$ZB zTUY%X?uQRNBYOumkGB}3yh_5DsG)F4+`afdK3;p&yLh{eL$JmfQqYMpE^umQ&lKc}o?D z5U>_18IE(-a%HA(c_0*wZ-R+!kT%NT{*!`?M{*w?DeGBx4kSxtTOT%yAz#gpq37o} z%`f>65e33kzE@R+%NgB1y(uVQ{8XQifR%Wl#)u0G3p?BB>#bmI%>qRT?B8NyVoE!h z_ZAZt5y2$r=^t!VP>9C$y;s>IahYz?n_i+6)j#0m*R>D6UUNFM;zh(k{-Eiaqsq>& z%oK^w*0noPIA>LD(u)NmOUK3;m)Sr|hzpUyUjO6cRkQI#fx2~-=k-eH$#FY+y_cwn z2x$tRtxb2jimTm0WoVgw4#uXpH*S*P1o`LBZI5W&HQqNH z5^hfqKT8fj{sz;Sn7iQ3w2s^U9sEdX1l`W5Y;)P>w)ym zTNYMJs)4jQbWL5%pugN=Q1YP%(xJq57%gTrH;)Jd5dtwEzIU|sXFggr z(!igi(JX|4xbSH*4r{E{;)seu(bi}6Y?(v(XXemt4+ovr0_nkyWZ-1D{Zl{viL z?0&xEi=5GzgE>oJJ7BXDJ@5GfMy8J+8|?O{;j_DSJ&UgyksOAts*Im}L>wHVMs}c| zM5B5Jd6sXs*6fzNi>r^n_xj-*L`jMJAtoen%fET=+W#xRphunnjWnR$B3Pj`v`xVq zDZl8`_m7N$frP*%)I~Ct@Gq0NC>L&kU76@9l!{n50h0{Pc0@ltQveTFeb)32;rysn z@=XMJTf2x}x+=4>6JJ43uIP``(@av)`-Y)Ue949kY={tgDamIqBiR4Pm^PK)sB67< zRbsiMzRe!EJm5gvlQ=|K*%DRXR#x)vFBzbxDb{$5xZzT=4TnV&%Z2$gBBH6SC4c%j ztSc}=K`DV+S?3ycmY1EKT3uLeC2+K?Ty2a<^68C{CnsGvw} zgqWD=^o&2~JqDurB93mv+eQN3yn5_v^6`eZsoN<#YYGj8!XdaBbw!EisjaT`kEw>x zrHAdrHM#ISeIB#BpZNp>p-cBfTXCI-3632W$T*r-RT8lEj3w;{E@&LnY)~-Fwpj#K zyap-?ypKTms0|_=N1d{UnS_hW*aTdfqE@Bdea*{n-x#tTk!cmrJ5M+4hujhE?JelP zd0$yXKYe8wfs#Snv!u-FS!5n_VyTQa`WywPdhrdUFLD)z?y~siK`9~a#9B~L#P2c? zq>|Ghlaay0L=cGZIqt`9$|g!s`&as#L@-_tp3Cdr^Tz&1Zql&=noZ=nNxEs zbew(I#CyS^WV=f$3kUI3_$-o#0q_t%RokZU5Y^upPq%x@7m1h7!ayxGy_DtaiyK3pK{5MSHP;e``f}&!@^S6bfvVUuxnfjPS4Ba&~A=A)Wu$#y2{XoQ~yZyM@aaa-T z^yvqmEg7%P{PeDU{la0@k5c+%=KucbPnr_OuYRp0u9Ukk8a zM-c`Zi9NiC<@)9ac17Os*q${#J-gAi^2x>F&d%fUX@U?F=Vj*uDH=KNau23dVIAUH z_uXA`1aSm`2f9HB!KG~3-OafJfK=f&_0$1{lPe{J^m0F6&aMorvvakO^stVJ z#B~98vA1#G3l+75iB{jC*9UAamqm2s_f!n8qvNSNx7;9YWpK_MwInN!n-u5Yb(BvY zuIQic9mj3v5FCxN%pHR@P@2!3Ug&#qwAnP`l2P5wfzYdx;c&Ge*zn{tW@gyh`eq=N zp~$67oAmg2d!gc_SOc-V;(|qknftNc&WI-6*T-+${^|Y`GY&EZ!|T8fX`X<9q2hZ1 zXVls^!Eu(QGCh@3un=ZbQ()b}m32gDg}7w?{>ljOtz67d&R=&&EFcD5FuDlYtp>gP z^JlgFAobUcUW@F*^s!HT8P*%DP)WP_e9gJ#y}aNZ|LsM>(; zs@#|WdWnaNOF1Glb|FI|UAD`~t^pl=@5RY2~Z}&w5Kh5F1E4t;aq(r#7Hc_)* zF8%_s-pAdboThKXas2MtxHoPu@`ifErR+JZDl3)UJf#SUkdNZ2SHw(_8|0!ByhIT~ z6~87Xh8{IPEm{+&42Co`2p92J=udw0JZi*`aGXE=kw@KdcUV8Ncfp#mRPiacA}u!M zv>H@61QYu*McHku4#Fb58uU!5-#0_Y)x@Gm=NzwG>6t1FuMX?X3h{z`BO?a*oy=3W zP~wVGT{_gi8M!c5&#=#9Z*k4TOsZoshU888hF%Iu6@;IT&Wcaym`)d>=Nd3E^O ziaq>=zWq+(yf|fnEB{XIIZ1S=bt6E6o-a?pVNEFOMtS4wBelmU}{rukC-1=+%M|t zy5tFclG@v^hk(w6LZaY;0o&~)8RBS)5n?5XZ)l|rt^L>GsXI z0?dYj+NSU)nxA4q60m@`S!dRQ4EM;t(DSM7KjY$e^6y!fhbD8br^YPYuWVi(KvjhP z-C8a@S`qJ=DBtl*XUsij5J9@xt+kQ9v!+cRT)Eo0UKq}luU#Lv=f2AD_a_@#c@fx( zP+WCkABbql?q+wSvm%jJy55ei0)ix@g-e*^Z(6o`KQ+QrC(~$bIdYii2j6g`b;B<43G;rQVb`dh7~OOKOg=H{$6Hx6IDZyAcz)$?X+;-7Do z*tzQWoKy6^nFk)0?QLY)XVI;x)} zJVV|dQoCroQn#m#uR^t3V&&{SG`AZRR3W;^rJILg;aKta2Y8Hm?aBfICJmg`p7>k} z44j|RZz9+V3X74T`}c{MUwUImg?6aSOblE@#}-w}qCnaF^9V)s_KWUI6V92H z6-w*{+m&m3Y+9woy@sO|N-5n`eAZeTjM34O>V`v>U%BDBDl&3XxoT}je=_&ahB4h{ zOcP>@m#Wbb($FBwTsEowF2H|#$Mu?YXZV7e&hEO53?3d^I+PTTEvD_?FH%htd4pF{ zkF2j;9xz@mixz3~V3amL(t+Yu*u-d{m4&QJWz5Ff>$b!!he7 z@MeR^{?*mj($c@)hai&gv)z)YDE*qS&=cL-+he*B=6JeB1S5dmcOhw7K^R|jCBJ=o zI2yV^QFIZCs;$ktz0f4_Jrv*uxHbf-`N73J6wTQk)TP;?KeO8c+Cx!mwzI{5=H61V zC`>O&{IbaS<5M_8UO(lz`gI8Iw-a*eKle<2Isbx>0-|}0p_9$dZt|(-t!Ymsft{(b zJm?Q7Y)#j|rRe=*eW2Wpy#M`9VjGn&bH8GExok%Hde*WmRWy2?>+U^w-`(9({MB+G z3)vYVAKD3%W}S#wAe;*NrwT#kvbiwoWDk;F?&WJAYW=BK60GGjqas)5?QOyFTRdW| zdYv78syl8gr@2}1&B{Vl304FmW6;Rg2${}yNHJ9_|2(7lYihB?KZg#dQS7216zib` zXOKr|7Q;f^Iy?T_nAp}z3!dku#MM~f;@FgU0oF)bWU`9Q^0p*Imluf*33P;FLW^5qfw zMikkK6p7R)X|5QYp1ctnMShyPspeb?@3HRxjbU=QvNp)Yes{6}Q%+WpI}kB%jX?8m zghD_)QsT2Vc-7Lcqs?D7Ly}iqNl77oZ)$k5nloLNh2>ZFl>=1O9L8SH$>;-4LxU34 z1MkU!XL#Nj{JWG8zt3Z-GFcEqD;HiI3!bm7t#R&E=~Lr);665++bTJZZ+GQxS?dT)ki5#8Nobsb()G(Bi|VF7opQgb$BNAoH_ zJ}%Q=w*3d9w1`FphxkQ{|CTf3^M#kUGMG*lJzqV8RIgtLo}JY2vu$6j`mQiF{?JEa zHbX2zMa%QeBn@zLcUsPZXd~u1N+NKOLx{g=02hvFc{&HuHyl?hNPvSd*`y>=O1Ecqy?6;HI zmYjVIp=mdf-5|D6jm?Lo?VCm~(Kf$4Wv`o!LIQr}1Bcj`RJ(J`8ynBLc0 zqD514`%v1&bd7zDc~&-XLhZ%XA+6nVFpY}{wYs!*O95G3A-{ib2puu0a|Y4nu|Haf zNuz4i?uY)?#0v;Sq!gIBxPL*lE3)fyD7~R1)~c%&7LrY+#mJ~V;Ar>j&-eD;jeeCn zkIFN9Q#|r?6Cm)1*4hRfnN{;k6`&}4J9@UF}Hh#bglo3a7d7+K{ zF)nuL5x(hT3iDaV1nYC@vK+T&6uIPJ%`vT=&q;VG>4eDYaH&AKVi6xDS#dFp3q1R?VKN0#KEW~hhW*O z4FA>qp+LfyZ@yHcuD{dA@MPrsI|3^bx#cQLJ!&27CeSgVX18f>8`Y!n)-)7 z9?s$0U$AMfKeoL%A*}`VB+j>Q#nn$xsM>1PTt{M%^_)he^_+!FM*YL3-6*n4W2LW- z=&7W)>7H$YYvzLKM&rEo8yvD9NE9!aG{3jB=j4kWEQlE*@D>#X%;#(fG{WJ^H!FB~ z`yTSbIaIy;0>iS&WOwhztWiY2ANS~euEIb>R3a{rT}JjhE%vSr?z4F#Di?*WNRLGS zD_ITxICSa~X(TiWbV5I7wKek!mqld?1Pf{L;7AN4+#gN0!SV=pEW9>F!P>=Lmj{*8 zO^tYe{^&o$)}uaFvue=~cY87!DPm%6G9R|t?@wJ=geQu9b3+x*WY5{zM$aBjUEslX z9|%dNXNEfZh|SjfcE_d|vJXg`X5sB={%xQUw9=k+o3777+xz}4z1Ed4hQ$BO(Y51h z$|OBd6{4~B_3VVetrm*rsS@f;Z+%fi!ud6|wvS>{HfW71Oi6yA(;R|*JZ=12TUgXs zHnSf;ovn$!y+FM)dw9WKt|oFBBT$LF5LS6&H`#MB#)*(b)cx;^5F%o~xp>W~^9S>z zM^aHMaqoqLyizy~wg=0nT>#K3kzIsj<(~8@2>Z!gZxXkdGuvD}*4_$ug3Xv{>lG`i z?f2uyr1w!+Df!(L$HUz+9C~8witg=IFWoP##=46=d7TH(eJDtiEPf`AJ3WMUbZxpT@!m~ZEM z;unukEgsuykQP>T~owx~fV!b^JNW%yzAE|Uy=)0eW9*8`B z<^x%Ds#+>OM4w#V-!9m9lWH{zV)s|wBgZz6b6lzQV{%E}D->jp1oTO+u&sV#t0QU; zg|4!+Sp@^+?$M$(VMxS^5 zY8Z}VPr4Uu7akHHXO{72Z(UWkGZ6PRR=jTN&rTlOuKoZxdLYfyvHq&`=HK+@>gqTW zDlWP9EFe%cEcYspNKY<|p9FJ#;SdWjvHtly^!IaRH#A&)Yp%NeJw^zkdF-}*^yXkn zXf!cjmB+kIb-OutHX#3it<$7?>@rkueQsS5?~D~&Jx?^qrlp44T>UtWiqO;8kO@T% zzUqlT&ftUx*)Cdai}>r`=KzJOzbPE!(X?$ktns9_`&E58tj=#oN8g9G6ekG@W%p^| zYiQ_LqL|C^6(?KmF3dVlc)UQ0cuz(D<{JJRlhg4Py49Iu#_*M9)`$e0EsglB)d~f@ zPU8(<9dcF;au$0_2uohqBbOtwg;8fHe=xc|@)R|6Ds#tTLWw^*tp=yXyx~~#WeD^{ z=6yn$WZS~~!h+8Q-8hxh^7VSOXqKtKThcHfGm>BelkqC!XH8G07Ahuy@cQ$AU6rFUC>*&%v? zb1QaDF*`e#{)IaH$EdjfTg;%h!%zjamH_GzDMS&3EK`DQbhaRB^3F2DJq;0`yW*jn z`I9wl4AKQbr{qDGq(QXn+Xw?%8Y&C)N}cMDOXoXf^$es7sSAeUk4sN6x88T`+iS54 zA&7u6;tR->M!t`y;k z&S~UOfAsS;!Fey;aYXp%i6JIlyobk2zVo}eCA(X(r`Gs6n?Qxq?vqa$GS{T8Efof0 zqX5;wNUJ7d{(yz->+8!;(gH@X)umzF^_OJvnL<5kOnf0uuRuz67(TCS6dS=|+|ez* zxBC~;)X|WK9VUM&2@)sFa7JmG{5XD1znI3xrpy@tc8PzK?L ze+1V6Q()Cas&Dl>WowpRZ@h}A+PLJGK9Hw{3qhOsxY&SH^nnX$XJ_@TRDT~c0jCM# z>gwZj6j4z#2~qrnp{L6FMF8RzS;N6N{{2Jz#b=&L7N*WUzO)uV&=o8B$ePB(qn&g@ zrN`eUqo5cu(nBE9Ec(n0+}sgKV&tG$hJo-960**nM8K)w+wqgQt;d_2m`xgvDXgjlf{qbgvQ`Y)No@ax{p!dt{0Lu)$< zt4!qET|^aS!>&;B?}q2*_F;`_}& z!ly?8%xGAQ%__l^ckYk3C+Rc89Ip}>^kT{=v%DvuMgA2+)cbl=RJ;l}{Gpdl2+&A( zX2sOFwILzrnw?zbB0VAb^O}GE5MI2XU)kC55x~QARzkBJ!}>IQd<0c$h|0}OJLB${wn6#oF_w;K!>iw(sgHj&7 z?0cPQWtxt6Z8@<`2jyDmkb!h>B;R|=uLFv2-e=^$&1zk4CHncRmQ~`d^g{Qh9t*%F%shk7>e6!|=2irsw`A zNoS|A-Q9s41oCj}zIrjW#^LGGxH>_`P zF|gPm@A#6$;5uY_SU0UqA}b0Z4mKx#qb7VPR8W)*&cG8@4xbHy1a16iG5VCP$sCtN zvGK;N(3pC282_@+F0j=<4<9A=sv|r0*7%7HpVGYrUaNfF+r&f-kl~Zo?v`JAS?f~r zas1<5UdToq*-X=O55=6%DbNq8WNw$i)-k{G^M|BMxz{S56GV3UM26FKoVxyf0M(B`hqW$p#;KOk%{^d?Y|PM7M0e#ZeGld`kJHqk+1By z$D0#_(Bpna1#nt%n-a`=mkEKyAI*0*A0x9r4C3Pbz$DDKu(TmiDP3RL3e7_#Ge4QW zo}WJx+HxmVkZx3TC`VZG75m%SL=3bBp|Wc>*V)EP$sjR*t{%6%0b4zY1R_B309P{^1j~K@PNm}_Mzm10xVT=i5R{wj+t5B@; z-9y#F)^@3opcj>M58@D`@Es6Tx1A8~A3ZB80yh7ChIz(DwmE()@`x9HYafnfD;&Q7 z^n;V*W~SA_EbrWp(=+?iPJERrGt>l)QrVWjpKa#O=u*RGqu<%c{G&lhpyi1ktD9xo z`l{&vJNE^Jz(l~h8jA3QC}ha`rMai)X>aZ?OQ5eh{aJQUTR+&0$0i!V*32yDRzrt{ ztuyqy=KeHuXqz{F%s?t|z8_`x+AS|TCo3W%pty-_^9vmaoPM=s7!X5N#B+&_qh(&PI-e^iw0Di!?s-9+zAXg1b84Z=$j)K>vHGi=Ee^(97y6AnzJd^f-$LV;KWBYd^DJwfa8a5pR&P@ zR0OmeJVRIaZqEps$J7|m^#SJ6ZZh|JHPT~iWC&Q8vjFDVwhA=@^cYK$@It%l)?>@M zbb7i%RG-Tn1K^H9zlsJ-i4j6$%y{AW<{@9dyErR>-j7f?J1&8@QH8I*gT-=P%$EY% zn)mO$I6fyB#HL5_TYTlyD6uNY{LDTbpJM5!_^Bi4<*MZ|pmOEqr_q#@j0(>;J-vVa zye=WHRsTixYzCs8?J{H)6g{z|lrb zE$dcqMV;7h_w=CB(~DX1zR1A9-?kZ-RaN-x9do)HDEqU4?+!y!%2Qh~PG+tg1e||g zCIx_6mG7IMBIEW-zIYWqE=z!P17c1n{ut4km9xHyoMm*h_@BXz-CvpQsx2qH9lB8) z`;D0S(}e0-xYd(qf7p1k68b7hY{{G9U@_Z3OsV1YjjFpfh~Evul+rYG^-Z(vKKC|i z8rm4ddlT8Lozs6r34|su?2w&{M|5l?M)yi{cB_}-u3F&2JRjYAgcpXr^Ox%J5ld?k zfJ7m#7sKJ8l68)g|8I2&g5k!S6}F#U%}K(-kiyEh^)ll*+~{b=-BtYz#7we_&WY^J z**~SHV0;UU+Bld9}?N!X~Lgn4Kw9RZ#^!!|0szBmseUE33w9)mo`O295qReeACQcT5zqN zO>7$-@q6Gh%k=2S`&3y4W-t)I0srw@=?;$mgj{|B0lD2aweSQy$k+W4(RMp^@dp?;$~aOHRIzXnXDkPWNuA=Eqm~CBpMwT*r%^dUI^q z>A5EnQpy;1Xk6{XQ|g-VIdy`#o|of7p?u}#7G=hAq&78_f5+~|NP9L~{(~#DcrQey z*dWV%%%1%q;RwnrNSk8e%*?80Y+oPq@o^j_dz|g-gHGQ*oG8$IRabu~InfpEw}4g( z11CLak&s|0=mG`sNzAlq|18PmvTJ_h%^lp^?~q7*l7AMstFjgC5Vw z4g2vx-;>d{Z3mL!y1d~eb7nMtt>Z7XzSOtWV-Kr25Y|EGud3%a&x};s%KY`e6`;BhXMEKeT>Ysec z|2K6KTF$83^J&yo<(QAv7XGpS1+cti4hTUeNE49 zpUw7O^}%i{Z6z#XH$`R+gw7=X(TCHi&ttHL6)#(v>AJ&;n2j>fgC!9HDHYC>faVZ* z< z*$rxPvO=}DmtP*eQGV{mz#}>$8d5)x*rQfn;=f>!%j&ng-w2(mfqA-}hpYm)dY-eB2xWN}H>B zZBo7b<#0MfMtbo!9b2GDRzW|RdNts>06*^-TUM8CAN(%_wdMXs+$hV=w-uH`gmimK z={_~BV@lH>C}lfdB_f&rBqk!6t}H}r4~?9P;CJZo)6{1G6uO-$m1xtIQr*|KIUWDe zoJJ0hzk9PdQX%Gl-0Xi=@OJVorG`8VnD-2&<;VmE®w_`d`gV3yjY{|b6NDG+(F z+Dfp*;kmaQ( zgpwxhnx_R<$?z+(zcBOG)xj(O-onKv&u}*Y!5QxL?cP`t?_fsj3Ui*C1C%hkGmf%^ z$sYlM5zvGrsp|LslzMZq9neG{PhO9SWE6y`=nDqj z1!%~VaeKI+f{24Yh5YfiTrykv1_s2|_N4heH8s^wYtsen8*a~)!^|IO3%vpGm`S1{nVrYa5Y=)!`dfCh0Rn_j zm(8`DmU7cSLw9JQWpjCopTxDauI}8wxVyF3n_>Ml8_BFdMt#r0e~v37)8hNY#B3_$ zfiq(6_mhS~fUxGc4Uesct@)l)-)3G`xg!LX*ly=n;_61Ce%o{7)XTJ^xpdD%0pY88 zN1%RdaOcWZOpDk`_r^Qh929y|N=iX#IE}EoixKkU;>s85%vWuxvKDu*Wq)CRHfT+r zGsd%^_-41J$(cGl94Iq+59(F4XZ=7A0hE}QjKol{eFad^uSSB(p%@Qe|YfeXzUdkFO8W_f}7`qNU|fp^x<*l}Vf9 z+x02ZF!KF&Fc*A>P3K}`N6!dbQY%|?u*bB|Ug&g&f1a-@{yN-FhZW!F`(0)kyOOSB z^qwFm@QUH4{V{Onv#wIpE&b^DdN^PK5W*Kt=Ch=>ysY-QhX2llv}W;fB?rB-yu0EP z!NZ`?HO(u*do2H}?Vn1ryc+5MDIF%=Eqm|wt=`ej?-WTXO#&|2>5S}b*t}wRpL@)j z(>GHG35bU|Ug1ztpIgzuFOQy>l zZ<11~->-5khf1P!O3D!^VSpbBTM(z(Eg3Tut#Kydl|mLJ6|7d}8?C3syj)qg74JK1 zqvgZ=-$6!^ufNp&tRL@uyoS4;YObq7cMxFrU zy=`(ee)9{8O^Y-aD0ZEByyvqX2J_rCP`)Xl7=tPHpceiW#~_Mi2NgY5RGB@$`p=xo z`J@hit(U+6ol>0*-51L12quiX^RW>$^2N>1gd`q?-giNn5G1yO6h63@FIncUZ(wYj z7@}UW8L%>c(y1vk?KRjX-rWT%GF%^oy4kmEFwIY_1A6?<$ONJ!0QNE5Rij{6){+33 zr$QDC2C|Hdoa=`~Pa*)daLWfu1nRPl>NGdOUM;chr({kr0@elnxsL`&wEuEHk*SVl zmI8e>KffhjfzQpagDx~gMc+FXMm{U?)7eU-&m^o){;gTn7ESH5|9%xqNjVOSGU+*JN?!^@FQXL%yo@TU$)hH`Q zs~s^1%AqYXb{luqdc%Pp&49gR9VTAk=PqFSe)*uNT8qN@>`>y z!!$xH_uUC11dA9x~48ZFS z`0DB)!=iXv2~`1*Gp=>N3>n~XA=J4u7)Bd1ePBJn+b-COB zOAF9)ePUf*n*X_O@THk|H`sJ*F7-P*Ee}^Hnt63_l|*j$_C{nwCu@>%^eniSe+YP? zVNv_LWS0!c!9|17zndPaV9~`=(IH4^8iIv7xw*)=cmhh?(Uu*gdWqHR$=mxmU+WEDh<=CA(S=MtUcBI}$q(dspoKg__2F0wzUgL@8?t=7 zV&8x~8uHxV_^-y)iwhKvpify|Ny+w%Wby~mv%DL~#P&*fr2@aa3t5j9>zWKh0(w*M z0cb3<0bS0_{V)9N*Mb%h^RGM~E^=$xfhrUOd#v&yi;Rt5%WElG?5RlVeS(`g5V;s# z9SR=S!_*XYpg@|MN?bo!52-0bx|3fI!KnUDpV-n233?7ayH|(7E6Wmz2iIt$Q`U0` z4Hw^mV?#{$ZL++RN~0F4|17yu^r7t=Vz$d<%~42wBVW^XHWYB%5b*yd7QK&zPet9%Octy%~{j4aaLGWQ&Ab33uzBsp*D@t z;ff|UalgK+w`yM=(cIX8;W9&7n}e{MgeeOocrEV#+^YpCrV8YQVoCY_GEp`1ki--x){S~laCA$%ViX;?S7!J_$ zZDQ9+65(mndK-T12*LRn(zb8GZIUZK4(05V#b)J47ohds?SNMv&TO6y_p>{i@dgBxvwK}DGV3NqJ_`|hzicY*f4-toWyBP=#DhG`^_1(( zqJOUK(_*6yrn4~jA_53Gx4#NZ+#tFbL^T&;YTEW-)E>lh*XZ28fkq_<&+Uc+rxKJ| zau}ud?OPj=B1q9AZJHsfWgl8y?qf8Z$O@Ycqe+1J#kSEInQy^~V03g&S=n%R_t3dE z?B*=3+VQZ7*c|{W{X1i}#`Omz8CfPMe>Y#vg5&nY>nl zTYMj>zosAhn{X0B{%-kVyaGuHB5i zmo!D14NAFtI2+ zxFf<(WH5s2{ny15IOxE`BS8(j5di{x$m#u1@>(O;QR7vxV^C-{?DsU+Th&s15f!xr zhy*{NQ&_CR|dJ2w--ev$C&PANTG!2#n;bM z%myW%Fm)x-gDEk?A)YQVh`NJrOoNE!IBYwj1Me7*-lflkHB1B>e=d? zJOY?+_uk87q6Aq-RU;(ZOe5%VgwPVj!ik3junQg=P5YgMUcM1@ z-6dnUgT%b*f@q&jto)@R?|eX9&FGYg{sCKQ!SiM)L#}tG;==aLuQEbmf+`=M3pUX0 zgL?2NFI{Xl$*lMLqm>oMP%4AOyC|C_)O;NIx5S~M-cYvg`46v6IH55S0b}PoH5DK& zQ=xCQLn$7gC9*LxI@Ybl(l|UETuf=rVj8pXhez3!3JiuXv!@=(d@AJHTWS_VGe@UD zcU=x>8Z;Q`D^T{={n=_ZP0q2K6Klso^TM^%V2bVM1g~IoN}ON)R0-u)BwI%{i{}NF z4(;xvI+S3fZsqV-q7!j4&(^leavS`@NfcpA7-rp?{hD?utMtLZ@Gzc_Pu)iO-sM7A zBvV&sq^UwkNK_Q#*RN`>ySQw6TSLKn^R;;mj)=duhNZrI2`oq@5ibmW_bXtq%*ZZ@ zJxhiq3yP*UlVZF39TUNcixz;wNj&`x&K5G1l#~F=r(QkrO^WV3c)YK;CYuOA@V#y) zH{3WxYrb~V{lSY0u1efIBEDPNHy|ycfrpGnhO<;rRvCQI6JN)QW?(???Pa)kguc^w z_^SM4@aGLYwi0wS$1MkY`dx>2Gp=xuD%)Yu0mHD`MC=@?Dst>+{d>-}y};I>k%#OM zF;Gg=c{A#<4w}N}nm+=8jO8i>7QRLASoigxk-S3;UAu;AeAjSW4X1-_-y+J9iN!F* zibk}xhwAvWFTqFrDCflK?v_gX`a--KGx{%f>}$$hD>4uH;I_7==h?binmVe_Qq!h* z^$Nnu>cBNMBK&_9_MPEyebKu|?>)LO(Sm5vJHsfE5TZtn7NSQ&ln~t@TBIYo45B4O zH%b_Sh~7IfdWjbGzvuow-RHUG>zO(G?0xpyYrU(zhlQiAXw;@SQ+a*?|7~eV{7v}qdubVtvZOoa?Bd{ndDwe!0eQ!ch@8{y2L#knCEQ_T850aAfExCG-WWT~ z+(g!$3XPCeBS^iJcDiLhonQ^wo?s%8%1xPl2yyu~#L46lRtB7{KfM>jT7+J=0H zV7AeTEZZiMQ^fG7qIchpXV6)4)a6t-99VK#xE}9}6yH`fZ}7jFjcnkx^8zC;s&p3emI!it_H1c;GA3Lj=C|9ty1%gP zjBCXEt*&@6{3MkkMNWmG=LfL0NdCK~c6*M~#D+vf!^k8tEua)Y8=<$Kj0!)XLc-Tx z`(EdzRy?d;Vwz?}(jJP}n;26hctgWUE84~lh2W2{^p_KM_sHHq@Yu5eyM}t^HC>zr zx(SZ|OnQln!e}pr$S`c1N!WWxbVitt8-y}<; zqSr=h-B~z!={v2hZ@Ns%Ubp)c5Uxib079D)RV z$s&lUTB|S5iPBf5Qa5w3iE zIjFxzh?mbSsy4q#b$RT6d~wXPp_Qc7@uyc#(Hlk&8a$nhZfh{m0f3i4^}4Can}VY4 zefK-N^%atX1omTjSTnZLhnQqd0)zxAcw9;Lyh(24(eU6oTP!!N>ii&IZL8rsi>n58 zyXhh0_Y$vNV+lBubEKwD=ulePn!fS2kb?Hmp+j7a*08?3yjr_&A|DHM{8#o;nKMPe zV3gmJsme9GeaUH|$#)_6kAa$pyfxT8(wAx0A%EZQiVmoG#!yFm6R>FY+%P}RR3Ivz zXXZY3Oev>EH+&sxm; z0wE+?jpdZrX;(bvI-{5`_bG4A#%lPVtbVr450TM`Zocec9i!y@5|sPBK8Kqx-|#+w z|Ew@1%K8e20x#!{wGb6n&|Yi(Dl?O-)TTbp%qD=SIuAW((xu@~V<(psfeM=!G{mp0 ziDY?>T&Y0NBW-zOcJ~MGE}kT;zn5^*EgtCus`9wKy#*{~x3O-ET;n4pZJ#R5(tEEM z1MW2i<5d1w)zm3mwX@%!$21m{j9 zLtr*bZ6{o4AkWMot2Z3M4L2~L9VxYrk7c<2{r>sVuU{+y8!V+gA0k>ovTf^=vbSyB z5LP$$F~YbTLR> z2JB1S>^JQR54UHNdV20`%rvqG9c{HAMA~{6N@)q_RvOwjH{TF2^qKXujh zoYGEn7ii1`KCM$`(^&p=^2pDQRi(U-u-=4kx|L8v}joqoNh) zL0(k#k|WqAkW5}=YPR+9&nu){&qMj3q4Se#4&6-Y2ZvgK7%W#pq{Kt$4q_Tm5%^jr zCML3|JeRYwvg)yBRO4=Grec5K=2#`;5JH@Mve&(%>_d2nhet_^7?yIt$%+Zc$otyiZk_-)*WoonH$6EB z2-`3y6Fw`R661ix@XjDt<1efi2MJwVGWvL5@fTQSTfSI7~7u`w~-#dQ%Qt5Hd<4~PjH=i9KQCC5XJf+LHr6qyjM;06mHjV6= zV$AxrelTi_Io(EkeP01VHU_{0_M`)JF`d09k9lLQVu2An+hfP0feJF%~7!Fw*k!a&gP6 zfF}<|iXRsj*TcjCH4hFl`1$#5URX6kyB+KYc-%@HoHtCtzWBm{Ua@a!Y0+7QdIyBw zkS}&5XgqydIlcy1YQjn^s}~m9;|&Up!Qi!p;St#&#nXQME;pY9{fEhF9=8>JV$vK@ zqyu;f!*WW;FfC3+V)T0!IpD4IY)<+*z(Dv=hL7)0DJNYO{&$cxC@!X;rLu&n=iM_V z_&wD`wZHLbONhQ-**>0tu8OsSXkqEr($Q)JEA;C6o#q5k@~G+awYFFrafG9HnMeou ztc5>4Ew`a7czAW9FIyrW2hXd6Dd+>TIpjpICbSiF)VjTNOOBA}+WKPBW6$3(+^@Ke zpU40=1Cb<0r(Vw{r+x@F4*@o>)14zcd@g8-^vvD?2&DqqFTh&#?a6yNx+d+!EICo? z!jzQGlVbd(C?dKhoA+7>L+4Hw?8kbBAPK*20L$6SE|gC7^=J zq3*U@KpbYiGBPZ>|T|wp#rD>obwtk6v(N$q76)(%3n5U)9eFa_NmxRV{5^u zuWyZ7ROL+kXUGLBM4SAYaQ))E*NR7iv0ey?>aO5YDnJr|L*r zDrOEHC<~XTesyIGVUr~OM?x*d$_A+c#J^9Y`a|B!Yw5-1`T27)#8oCsAcx&wX(%JN zX;ib8_8*;#zPz3piTU}4ze+97Yb`a+IWho*48ZSEZ5t{K)9u0SX`yl>rcw@ z4Z)`nT+P>zuJl(1MJ88BsE}NZ2pW;&hwCe~w#kJ+2U6!uWBoW}Xl;&MGAaJ?cP5_6 z4nzx+C&pNWK@A^0upa~my=lKqO}Te#SH%BJNGAqmiAGs7B8EJMh)BW0aC#jaX2fU| zuy(}t;yz8s_|p0Lb#9oXn4^vay=Y>{;NW-CDqXle-lGeSv5$6r#2bxkzl>j12+j&aMaf?fBHny;`_#^Z3^0p zOBZz1J82OYQBYhn5r94Oi{3;TVt3!6o9$W&BSuY~oELwc96-%Q1hvI(#h~%D4VUh-X@d;?mq@>W+5+fjwnn?ecxFgklNg$^ z_S=(hN9(|32lixoRo=mEx0rcogBM!*xK`mN9e7PJfJXN%YG}_#OCow&;AJoQWtppI zgPEZRt7~x|2k!AkM!{1v%gjp82KWGKqex=BF<14FN@#Gvd$|H*5O~oLQX9{la(Xb@ zIaAA^LPDc%|ETct-*WfD-wjNn=IXz{H5K01B0sWK+|l%rh|^D3J0am}J|8xluktJD z-;TIx0)mdDRGRbiZNz9*O-$mo&CTkYJF}Nsea@e1S5^$VaYRnTU%6zd!QRHMD1Y+D zuYM~M@jVCs&FX5++#*5Ja(6%INoP7dJUZj>aN-L|lOl6MpA$pLosQm=WMTHrkPaic zab7_V&~GNJtf4U2lSvtHiE^quyDNwZgIOGLD_bpy2SEicNn+q#y-rso0b2~gJT@)H z64;`amb)Jxo%rf_xIb9grumS|6SufvU~NnY8bt%IJd<$`Jsrr`QxS7mH=P!H3J(od zgE+WCSnj#GUBPtZz!ccj^{57B0x5StFNW^Y*}L|=OkP(H#3v)&XZ!boeLuF{7qc2Zsi zXC#Lo=UMEWA3f&b#)k~ve27gGYmCg}yZt~lL@6Ek*$z6S?&oI~m3#9UFV1gMQjOTy zumtQ2d}(ah|LJl=C>bakPxKKd1OpbNUrd5tLR&lH=!;t|w)O$u3Hr3O1~SpRMJC$! zDItg9Is}36oUvRN80dX;+&dz%5GhsOjbvd1en&^Lb^QZLN2E;!P;`ia zSA4WmY`kSwWT(x|Zdd6cuJ;zu78M&l-{XDt z4p1rPYA?S2CMgOE`S)p5)Rr?8duJqp>Dl$iZcQhs6J(uIOs;1<`_bq6v)eG_ps4>; z;Z8b=f`H1jq_Vs^W^~ePl$o9oVEvbNL5Ij}JcyTxiKWuFc` zq@d8r)Vr;c68Dtu+I;W928W1w&8mRy1~etpQ*%$S2Du>20gkaOfc7{h z<(Mtd+Dd0A8K{kT(6ii)Jv~Be{8<{p{#{$JUji69EuMMtWeka^URrcL85!|*ehDfR z_@aTJ?F1ZPn$z9IwCANiTJb^PYau}I{)hg+K(BH9SgRRqaD9L7!NbTJ^obDf*AA** zK==gMC|#t!8@@Nr7N6kmUukDk$x;>f|KE__{5c_3RFJYRlJ_9)e{go!$&)V$evbwA8w- zmG<5Ew}f9T6(GVowBxNA)lC>nRZoS1NHz!j>3O(q8L&dV#m}pj z@tzb|DFO6Tvi9BG-!qLj-qKZ0@RwC@j1OYT-%weyQ2HherA$o7SeikAM@81Mz>d@~ zt)@2s=qp!Of>#Jp%;t;B`f)d4o@`!BA#T%DapDf%DeQ?)_1E^^E$O zrPu01S(mDss;7eK&OI(?x2*yBxO#YaySHuMTJrHPwV{f+ zmAYfOiM;@FA|U^a8u%slwZMQ_QIf&CK1e2P+u7l@gYKTI(&WDeKl1?L1j^fO;M-)X z;GiK99Hn~GZdgxEmKf21$o@^iRp8<}LiWFw#ZBOOxqZ1XvbP*+8V^j!OT4N&?}AgZpye1q&=$Khe-I|zw;0~CUjzpDwdFz&^RwIs~~Tw ziD@!t1bD{?1o0RNA+mQJgf_5DN)m>80kty{T{00Q@fgkPcjGVsHn37r0dWC-EOJF; zTr9VQkyFLJk_b_3I@*_)tg|n3A))mLYmR;x0n2J`_8COKYj`e?Q-R=svTs~ukF*1; z>lo^LdEuQQsjY;Td7<)C%+~Wz0iFxr`|7kH77$e}yP=gpuL|O+SCT~19yRsNR8gq= zR{7fuhK09H7n`+Hl~Hz$eI+uve;BM0j(C!_gQk90vM`igJ}NE z2FL6tu*-L3U&UEM>Fin6OEL;YMJSYCj7Ak$C!p&oMJ4h~iVb~Eq(aCj5hpQRaoa(q zR)wH{ z^n3uin$*Mu1lEZ-MwpGTi>Q$7STl6{Fz;ksr-nXgL@e1QN>a?~JcU;l8x){uaN|=aZsOKA!Xr=&M_~-3G|(=@>c$fuUlB0Nx#_L)dBV2K(LV8W_blN@@fVJ_p&b)x3flVFDI~)w`FB1 z$7>nP{`7mA$@uC<&uGJ-w&lji+FnSF(r3LgSdqoD=#%w(LUi-1&ZtpGAn ztD`_Kup2SDYuiG9eOVs;g833>)skAV!tA)$k z6K()EIg{BY)Tzt{f<{#@?^n;iMuZpj+}RDL$iK&7Rp|bk$Q~K|AgiY4RYiu<8;zK_ zqu1=LVlbmZ@uk$e-a*p}IP*3@!JGvw8ow_KInV)G!m$uMjq}tCN@{^Z7NrGdbn2S4L7i+}z$vohe#9SBJ;J zrw3ec-w4=ttFk~1yE-~K*&VD6Bi+mYqU3k3Ta$eAS=N1G7KXgTYg7mpzjdl|@5T+C zk}nq7T7P&_x+j&6b%aF{JiiQ&J2^RB6BO*48g^lFHo`_ are used to map isotope to hash values with which all possible isotopes can be described. - - :ref:`NXoptical_system_em`: - A base class to store for now qualitative and quantitative values of frequent interest - which are affected by the interplay of the components and state of an electron microscope. - Examples are the semiconvergence angle or the depth of field and depth of focus, the magnification, or the camera length. - - :ref:`NXpeak`: - A base class to describe peaks mathematically. - - :ref:`NXcircuit`: - A base class to describe a logical unit of at least one integrated circuit. - - -.. _EmAnalysisClasses-BC: - -We provide specific base classes which granularize frequently collected or analyzed quantities in specific application fields of electron microscopy to deal -with the situation that there are cases were logical connections between generated data artifacts mainly exist for the fact that the data artifacts were -collected during a workflow of electron microscopy research (e.g. taking measurements and then performing method-specific analyses generating new data and conclusions). -We see a value in granularizing out these pieces of information into own classes. In fact, one limitation of application definitions in NeXus, exactly as it applies for serialization -of information also more generally, is currently that they define a set of constraints on their graph of controlled concepts and terms. - -If we take for example diffraction experiments performed with an electron microscope, it is usually the case that (diffraction) patterns are collected in the session at the microscope. -However, all scientifically relevant conclusions are typically drawn later, i.e. through post-processing the collected diffraction (raw) data. These numerical and algorithmic steps -define computational workflows were data from an instance of an application definition such as NXem are used as input but many additional concepts, constraints, and assumptions -are applied without that these demand necessarily changes in the constraints on fields or groups of NXem. If we were to modify NXem for these cases, -NXem would combinatorially diverge as every different combination of required constraints demands having an own but almost similar application definition. -For this reason, method-specific base classes are used which granularize out how specific pieces of information are processed further to eventually enable their -storage (i.e. serialization) using NeXus. - -More consolidation through the use of NXsubentry classes should be considered in the future. For now we use an approach whereby base classes are combined to reuse vocabulary and a hierarchical organization of pieces of information with specific constraints which are relevant only for specific usage of such data by specific tools used by an eventually smaller circle of users. - - :ref:`NXem_method`, :ref:`NXem_ebsd`, :ref:`NXem_eds`, :ref:`NXem_eels`, :ref:`NXem_img`, :ref:`NXem_correlation`: - Base classes with method-specific details especially when it comes to reporting post-processed data within electron microscopy. - - :ref:`NXcrystal_structure`: - A base class to store crystalline phase/structure used for a simulation of diffraction pattern and comparison of these pattern against patterns to support indexing. - - :ref:`NXroi`: - A base class to granularize information collected and relevant for the characterization of a region-of-interest. diff --git a/manual/source/classes/base_classes/mpes-structure.rst b/manual/source/classes/base_classes/mpes-structure.rst deleted file mode 100644 index 4610b5f90..000000000 --- a/manual/source/classes/base_classes/mpes-structure.rst +++ /dev/null @@ -1,77 +0,0 @@ -.. _Mpes-Structure-BC: - -======================================= -Photoemission & core-level spectroscopy -======================================= - -.. index:: - IntroductionMpes - MpesAppDef - MpesBC - MpesCommonBC - MpesExtendedBC - - -.. _IntroductionMpes-BC: - -Introduction -############ - -Set of data storage objects to describe multidimensional photoemission (MPES) experiments including x-ray photoelectron spectroscopy (XPS), ultraviolet photoelectron spectroscopy (UPS), -hard x-ray photoelectron spectroscopy (HAXPES), angle-resolved photoemission spectroscopy (ARPES), two-photon photoemission (2PPE) -and photoemission electron microscopy (PEEM). Also includes descriptors for advanced specializations, such as spin-resolution, time resolution, -near-ambient pressure conditions, dichroism etc. - -.. _MpesBC-BC: - -Base Classes -############ - -:ref:`NXelectronanalyser`: - A base class to describe electron kinetic energy analizers. Contains the collective characteristics of the instrument such as energy resolution, and includes the following subclasses: - - :ref:`NXcollectioncolumn`: - Base class to describe the set of electronic lenses in the electron collection column (standard, PEEM, momentum-microscope, etc.). - - :ref:`NXenergydispersion`: - Base class to describe the energy dispersion sytem (hemispherical, time-of-flight, etc.). - - :ref:`NXspindispersion`: - Base class to describe the set of electronic lenses in the electron collection column. - -:ref:`NXmanipulator`: - A base class to describe the complex manipulators used in photoemission experiments, often with > 4 degrees of freedom, - cryogenic cooling and other advanced features. - -Four base classes to describe data processing, which can be used as subclasses of :ref:`NXprocess` if describing post-processing or as subclasses of :ref:`NXdetector` if describing live, electronics level processing: - - :ref:`NXcalibration`: - A base class to describe the 1D calibration of an axis, with a function mapping a raw data scale to a calibrated scale with the same number of points. - - :ref:`NXdistortion`: - A base class to describe the 2D distortion correction of an axis, with a matrix mapping a raw data image to a undistorted image. - - :ref:`NXregistration`: - A base class to describe the rigid transformations that are applied to an image. May be redundant as they can be described with :ref:`NXtransformations`. - - :ref:`NXprocess_mpes`: - A base class specializing :ref:`NXprocess`, describing events of data processing, reconstruction, or analysis for photoemission-related data. - -.. _MpesCommonBC-BC: - -Common Base Classes -################### - -There are related base classes that are common to other techniques: - - :ref:`NXlens_em`: - A class to describe all types of lenses. Includes electrostatic lenses for electron energy analysers. - - :ref:`NXdeflector` - A class to describe all kinds of deflectors, including electrostatic and magnetostatic deflectors for electron energy analysers. - - :ref:`NXresolution`: - Describes the resolution of a physical quantity, e.g. the resolution of the MPES spectrometer. - - :ref:`NXfit`, :ref:`NXpeak`, :ref:`NXfit_background`, :ref:`NXfit_function`, :ref:`NXfit_parameter`: - Base classes for describing a fit procedure, e.g. a peak fitting in energy space in XPS. \ No newline at end of file diff --git a/manual/source/classes/base_classes/optical-spectroscopy-structure.rst b/manual/source/classes/base_classes/optical-spectroscopy-structure.rst deleted file mode 100644 index cf610fc21..000000000 --- a/manual/source/classes/base_classes/optical-spectroscopy-structure.rst +++ /dev/null @@ -1,199 +0,0 @@ -.. _Optical-Spectroscopy-Structure-BC: - -==================== -Optical Spectroscopy -==================== - -.. index:: - Ellipsometry - Raman - DispersiveMaterial - - -.. _Ellipsometry-BC: - -Ellipsometry -############ - -Ellipsometry is an optical characterization method to describe optical properties of interfaces and thickness of films. -The measurements are based on determining how the polarization state of light changes upon transmission and reflection. -Interpretation is based on Fresnel equations and numerical models of the optical properties of the materials. - -In the application definition, we provide a minimum set of description elements allowing for a reproducible recording of ellipsometry measurements. - -.. _Raman-BC: - -Raman -############ - -Raman spectroscopy is a characterization method to analyze vibrational properties for liquids, gases, or solids. -The measurements is based on the inelastic light scattering due to the material's vibrations. -Interpretation can be done based on peaks, which represent the phonon properties (intensity, center, width). - -The application definition contains a minimum of descriptive elements required to understand Raman spectroscopy measurements. - - -Application Definitions ------------------------ - - :ref:`NXoptical_spectroscopy`: - A generic application definition for spectroscopy measurements. This includes in particular ellipsometry and Raman spectroscopy measurements, but also other techniques such as photoluminescence, transmission, and reflection measurements. The requirements are: (i) an incident photon beam, (ii) a detector to measure scattered/emitted photons, and (iii) a sample. - - :ref:`NXellipsometry`: - An application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. - - :ref:`NXraman`: - An application definition for Raman spectroscopy measurements. - - -Base Classes ------------- - -This is the set of base classes for describing an optical experiment. - - :ref:`NXbeam_device` - Beam devices are used to relate a beam, which has always at least one origin - and at least one destination. - - By referencing the beam devices with each other, a beam path can be - constructed. This can be used for vizualization or beam propery modeling - along the beam path. - - :ref:`NXbeam` - Beam properties such as intensity, polarization, wavelength or direction. - - :ref:`NXdetector` - A detector for signal detection. - - :ref:`NXsource` - A light source such as laser, lamp or LED. - - :ref:`NXmonochromator` - A monochromator is often used to energetically disperse the scattered or emitted light. - - :ref:`NXlens_opt` - Description of an optical lens. - - :ref:`NXwaveplate` - A waveplate or retarder. - - :ref:`NXsensor` - Specify external parameters that have influenced the sample such as - varied parameters e.g. temperature, pressure, pH value, beam intensity, etc. - - - -.. _DispersiveMaterial-BC: - -Dispersive Material -################### - -A dispersive material is a description for the optical dispersion of materials. -This description may be used to store optical model data from an ellipsometric analysis -(or any other technique) or to build a database of optical constants for optical properties of materials. - -Application Definition ----------------------- - - :ref:`NXdispersive_material`: - An application definition to describe the dispersive properties of a material. - The material may be isotropic, uniaxial or biaxial. Hence, it may contain up - to three dispersive functions or tables. - - - -Base Classes ------------- - -There is a set of base classes for describing a dispersion. - - :ref:`NXdispersion` - This is an umbrella base class for a group of dispersion functions to describe the material. - For a simple dispersion it may contain only on NXdispersion_function or NXdispersion_table entry. - If it contains multiple entries the actual dispersion is the sum of all dispersion functions and tables. - This allows for, e.g. splitting real and imaginary parts and describing them seperately or - adding a dielectric background (e.g. Sellmeier model) to an oscillator model (e.g. Lorentz). - - :ref:`NXdispersion_function` - This dispersion is described by a function and its single and repeated parameter values. - It follows a formula of the form ``eps = eps_inf + sum[A * lambda ** 2 / (lambda ** 2 - B ** 2)]`` - (Sellmeier formula). See the formula grammar below for an ebnf grammar for this form. - - :ref:`NXdispersion_single_parameter` - This denotes a parameter which is used outside the summed part of a dispersion function, - e.g. ``eps_inf`` in the formula example above. - - :ref:`NXdispersion_repeated_parameter` - This denotes arrays of repeated parameters which are used to build a sum of parameter values, e.g. - ``A`` and ``B`` are repeated parameters in the formula above. - - :ref:`NXdispersion_table` - This describes a tabular dispersion where the dielectric function is an array versus wavelength or energy. - -Formula Grammar ---------------- - -Below you find a grammar to which the formula should adhere and which can be used to parse and -evaluate the dispersion function. The terms ``single_param_name`` and ``param_name`` should be -filled with the respective single and repeated params from the stored data. -The grammer is written in the `EBNF `_ dialect -of `Lark `_, which is a parsing toolkit for python. -It is easily translatable to general EBNF and other parser generator dialects. -`Here `_ is a reference implementation in Rust/Python with a -`grammar `_ -written in `lalrpop `_. - -.. code-block:: - - ?assignment: "eps" "=" kkr_expression -> eps - | "n" "=" kkr_expression -> n - - ?kkr_expression: expression - | "" "+" "1j" "*" term -> kkr_term - - ?expression: term - | expression "+" term -> add - | expression "-" term -> sub - - ?term: factor - | term "*" factor -> mul - | term "/" factor -> div - - ?factor: power - | power "**" power -> power - - - ?power: "(" expression ")" - | FUNC "(" expression ")" -> func - | "sum" "[" repeated_expression "]" -> sum_expr - | NAME -> single_param_name - | SIGNED_NUMBER -> number - | BUILTIN -> builtin - - ?repeated_expression: repeated_term - | repeated_expression "+" repeated_term -> add - | repeated_expression "-" repeated_term -> sub - - - ?repeated_term: repeated_factor - | repeated_term "*" repeated_factor -> mul - | repeated_term "/" repeated_factor -> div - - ?repeated_factor: repeated_power - | repeated_power "**" repeated_power -> power - - ?repeated_power: "(" repeated_expression ")" - | FUNC "(" repeated_expression ")" -> func - | SIGNED_NUMBER -> number - | NAME -> param_name - | BUILTIN -> builtin - - FUNC.1: "sin" | "cos" | "tan" | "sqrt" | "dawsn" | "ln" | "log" | "heaviside" - BUILTIN.1: "1j" | "pi" | "eps_0" | "hbar" | "h" | "c" - - %import common.CNAME -> NAME - %import common.SIGNED_NUMBER - %import common.WS_INLINE - - %ignore WS_INLINE - diff --git a/manual/source/classes/contributed_definitions/apm-structure.rst b/manual/source/classes/contributed_definitions/apm-structure.rst index 2cbeaae4a..10e2c77c3 100644 --- a/manual/source/classes/contributed_definitions/apm-structure.rst +++ b/manual/source/classes/contributed_definitions/apm-structure.rst @@ -1,35 +1,38 @@ .. _Apm-Structure: -===================== +========================= Atom-probe tomography -===================== +========================= .. index:: IntroductionApm ApmAppDef ApmBC - StatusQuoApm + WhatHasBeenAchieved ApmParaprobeAppDef - ApmGermanNfdi + ApmParaprobeNewBC + NextStep + + + .. _IntroductionApm: Introduction -############ +############## -Set of data schemas to describe the acquisition, i.e. measurement side, the extraction of hits from detector raw data, -steps to compute mass-to-charge state ratios from uncorrected time of flight data, the reconstruction, and the ranging, i.e. identification of peaks in the mass-to-charge-state ratio histogram to detect (molecular) ions. -The data schemas can be useful to generate data artifacts also for field-ion microscopy experiments. +Set of data storage objects to describe the acquisition/measurement side, the reconstruction, and the ranging for atom probe microscopy experiments. The data storage objects can be useful as well for field-ion microscopy experiments. .. _ApmAppDef: Application Definition ###################### +It is proposed to use one application definition to serve atom probe tomography +and field-ion microscopy measurements, i.e. the data collection with the instrument: + :ref:`NXapm`: - A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes in a process called ranging. The structure of the schema has been designed to also document a simulation of an atom probe - experiment. Having a combined schema for the measurement and the simulation is beneficial to document that - there are many similarities between the measurement and a computer simulation of it. + A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes in a process called ranging. .. _ApmBC: @@ -40,245 +43,284 @@ The following base classes are proposed to support modularizing the storage of p :ref:`NXchamber`: A base class to describe a component of the instrument which houses other components. - A chamber may offer a controlled atmosphere to execute an experiment and/or offer functionalities - for storing and loading specimens. + A chamber may offer a controlled atmosphere to execute an experiment and/or offer functionalities for storing and loading specimens. - :ref:`NXcoordinate_system_set`, :ref:`NXcoordinate_system`: - Base classes to describe different coordinate systems used and/or to be harmonized + :ref:`NXcoordinate_system_set` + A base class to describe different coordinate systems used and/or to be harmonized or transformed into one another when interpreting the dataset. - :ref:`NXion`: (about to become replaced by :ref:`NXatom_set`) - A base class to describe molecular ions with an adjustable number of atoms/isotopes building each ion. - For the usage in atom probe research the maximum number of atoms supported building a molecular ion - is currently set to a maximum of 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with - which all possible nuclides (stable, radioactive, or synthetically generated ones) can be described. + :ref:`NXion`: + A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion + is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with + which all possible isotopes can be described. :ref:`NXfabrication`: - A base class to bundle manufacturer/technology-partner-specific details about - a component or device of an instrument. + A base class to bundle manufacturer/technology-partner-specific details about a + component or device of an instrument. - :ref:`NXpeak`: (about to become complemented by NXpeak_fitting) + :ref:`NXpeak`: A base class to describe peaks mathematically to detail how peaks in - mass-to-charge-state ratio histograms (aka mass spectra) are defined and - labelled as iontypes. + mass-to-charge-state ratio histograms (aka mass spectra) are + defined and labelled as iontypes. :ref:`NXpump`: - A base class to describe details about pump(s) used as components of an instrument. + A base class to describe details about pump(s) of an instrument. :ref:`NXpulser_apm`: - A base class to describe the high-voltage and/or laser pulsing capabilities. + A base class to describe the high-voltage and/or laser pulsing capabilities of + an atom probe microscope. :ref:`NXreflectron`: A base class to describe a kinetic-energy-sensitive filtering device - for time-of-flight (ToF) mass spectrometry. + for time of flight (ToF) mass spectrometry. :ref:`NXstage_lab`: A base class to describe the specimen fixture including the cryo-head. - Nowadays, stages of microscopes represent small-scale laboratory platforms. + Nowadays, these stages represent small-scale laboratory platforms. Therefore, there is a need to define the characteristics of such stages in more detail, especially in light of in-situ experiments. Many similarities exists between a stage - in an electron microscope and one in an atom probe instrument. Both offer fixture - functionalities and additional components for applying e.g. stimuli on the specimen. - -Microscopy experiments, not only taking into account those performed on commercial instruments, offer users to apply a set of -data processing steps. Some of them are frequently applied on-the-fly. For now we represent these steps with specifically named -instances of the :ref:`NXprocess` base class. - -Several base classes were defined to document processing of atom probe data with established algorithms: - - :ref:`NXapm_hit_finding`: - A base class to describe hit finding algorithm. + in an electron microscope and one in an atom probe instrument. Both offer fixture functionalities and additional components for applying e.g. stimuli on the specimen. - :ref:`NXapm_volt_and_bowl`: - A base class to describe the voltage-and-bowl correction. +Microscopy experiments, not only taking into account those performed on commercial instruments, offer the user usually to apply a set of data processing steps. Some of them are frequently applied on-the-fly. For now we represent these steps with specifically named instances of the :ref:`NXprocess` base class. - :ref:`NXapm_charge_state_analysis`: - A base class to document the resolving of the charge_state. - :ref:`NXapm_reconstruction`: - A base class to document the tomographic reconstruction algorithm. - - :ref:`NXapm_ranging`: - A base class to document the ranging process. - - :ref:`NXapm_msr`, :ref:`NXapm_sim`: - Respective base classes that serve as templates to compose the :ref:`NXapm` application definition from. - -These base classes are examples that substantiate that data processing steps are essential to transform atom probe measurements or simulations into knowledge. Therefore, these steps should be documented -to enable reproducible research, if possible even numerical reproducibility of the results, -and learn how pieces of information are connected. In what follows, an example is presented how an -open-source community software can be modified to use descriptions of these computational steps. - -A detailed inspection of spatial and other type of filters frequently used in analysis of atom probe -data revealed that it is better to define atom-probe-agnostic reusable concepts for filters: - - :ref:`NXspatial_filter`: - A base class proposing how a point cloud can be spatially filtered in a specific yet general manner. - This base class takes advantage of :ref:`NXcg_ellipsoid_set`, :ref:`NXcg_cylinder_set`, - and :ref:`NXcg_hexahedron_set` to cater for commonly used geometric primitives in atom probe. - The primitives are used for defining the shape and extent of a region of interest (ROI). - - :ref:`NXsubsampling_filter`: - A base class for a filter that can also be used for specifying how entries - like ions can be filtered via sub-sampling. - - :ref:`NXmatch_filter`: - A base class for a filter that can also be used for specifying how entries - like ions can be filtered based on their type or other descriptors like hit multiplicity. - -The respective research software here is the `paraprobe-toolbox `_ -The software is developed by `M. Kühbach et al. `_. -For atom probe research the proposal can also serve as a blue print how computational steps of other software -tool including commercial ones could be developed further to benefit from NeXus. +Like every research community data processing steps are essential to transform measurements +into knowledge. These processing steps should be documented to enable reproducible research +and learn how pieces of information were connected. In what follows, an example is presented +how an open-source community software can be modified to use descriptions of these computational +steps. The respective research software here is the `paraprobe-toolbox `_ .. _IntroductionApmParaprobe: apmtools ######## -The paraprobe-toolbox is an example of an open-source parallelized software for analyzing -point cloud data, for assessing meshes in 3D continuum space, and for studying the effects of -parameterization on descriptors of micro- and nanoscale structural features (crystal defects) -within materials when characterized and studied with atom probe. +One tool is the paraprobe-toolbox software package in the the apmtools container. +The software is developed by `M. Kühbach et al. `_. + +Here we show how NeXus is used to consistently define application definitions for scientific software +in the field of atom probe. In this community the paraprobe-toolbox is an example of an +open-source parallelized software for analyzing point cloud data, for assessing meshes in +3D continuum space, and for studying the effects of parameterization on descriptors +which describe the micro- and nanostructure of materials that are studied with +atom probe microscopy. The need for a thorough documentation of the tools in not only the paraprobe-toolbox was motivated by several needs: -First, users of software would like to better understand and also be able to study for themselves -which individual parameters and settings for each tool exist and how configuring these -affects analyses quantitatively. This stresses the aspect how to improve documentation. +First, users of software would like to better understand and also be able to +study for themselves which individual parameters and settings for each tool exist +and how configuring these affects their analyses quantitatively. -Second, scientific software like paraprobe-toolbox implement numerical/algorithmical -(computational) workflows whereby data coming from multiple input sources -(like previous analysis results) are processed and carried through more involved analyses -within several steps inside the tool. The tool then creates output as files. This -provenance and workflow should be documented. +Second, scientific software like the tools in the paraprobe-toolbox implement a +numerical/algorithmical (computational) workflow whereby data from multiple input sources +(like previous analysis results) are processed and carried through more involved analysis +within several steps inside the tool. The tool then creates output as files. Individual tools of paraprobe-toolbox are developed in C/C++ and/or Python. Provenance tracking is useful as it is one component and requirement for making -workflows exactly numerically reproducible and thus to enable reproducibility (the "R" -of the FAIR principles of data stewardship). +workflows exactly numerically reproducible and thereby empower scientists +to fulfill better the "R", i.e. reproducibility of their daily FAIR research practices. -For tools of the paraprobe-toolbox each workflow step is a pair or triple of sub-steps: -1. The creation of a configuration file. -2. The actual analysis using the Python/or C/C++ tools. -3. The optional analyses/visualization of the results based on data in NeXus/HDF5 files generated by each tool. +The paraprobe-toolbox is one example of a software which implements a workflow +via a sequence of operations executed within a jupyter notebook +(or Python script respectively). Specifically, individual tools are chained. +Convenience functions are available to create well-defined input/configuration +files for each tool. These config files instruct the tool upon processing. -.. _StatusQuoApm: +In this design, each workflow step (with a tool) is in fact a pair (or triple) of +at least two sub-steps: i) the creation of a configuration file, +ii) the actual analysis using the Python/or C/C++ tools, +iii) the optional post-processing/visualizing of the results inside the NeXus/HDF5 +files generated from each tool run using other software. -What has been achieved so far? -############################## -This proposal summarizes work of members of the FAIRmat project, which is part of the `German -National Research Data Infrastructure `_. The here detailed -proposal documents how all tools of the paraprobe-toolbox were modified to generate -only well-defined configuration files as accepted input and yield specifically formatted output -files according to the following NeXus application definitions. +.. _WhatHasBeenAchieved: -Data and metadata between the tools are exchanged with NeXus/HDF5 files. This means that data -inside HDF5 binary containers are named, formatted, and hierarchically structured according -to application definitions. +What has been achieved so far? +############################## -For example the application definition NXapm_paraprobe_config_surfacer specifies +This proposal summarizes work of members of the FAIRmat project, which is part +of the German National Research Data Infrastructure aimed at a change of the paraprobe-toolbox +and its interaction with files for all tools so that only well-defined configuration files +are accepted as input and results end up as specifically formatted output. For this +NeXus application definitions are used. + +Data and metadata between the tools are exchanged with NeXus/HDF5 files. +Specifically, we created for each tool an application definition (see below) +which details all possible settings and options for the configuration as to +guide users. The config(uration) files are currently implemented as HDF5 files, +whose content matches to the naming conventions of the respective `config` application +definition for each tool. As an example NXapm_paraprobe_config_surfacer specifies how a configuration file for the paraprobe-surfacer tool should be formatted -and which parameters it contains including optionality and cardinality constraints. +and which parameter it should and/or may contain. -Thereby, each config file uses a controlled vocabulary of terms. Furthermore, -the config files store a SHA256 checksum for each input file. This implements a full -provenance tracking on the input files along the workflow. +That is each config file uses a controlled vocabulary of terms. Furthermore, +the config files store a SHA256 checksum for each input file. +This implements a full provenance tracking on the input files along the +processing chain/workflow. -As an example, a user may first range their reconstruction and then compute spatial +As an example, a user may first range their reconstruction and then compute correlation functions. The config file for the ranging tool stores the files which hold the reconstructed ion position and ranging definitions. -The ranging tool generates a results file with the labels of each molecular ion. +The ranging tool generates a results file with the ion type labels stored. This results file is formatted according to the tool-specific `results` -application definition. The generated results file and the reconstruction is -imported by the spatial statistics tool which again keeps track of all files -and reports its results in a spatial statistics tool results file. - -This design makes it possible to rigorously trace which numerical results were achieved -with specific inputs and settings using specifically-versioned tools. Noteworthy -this includes Y-junction on a graph which is where multiple input sources are -combined to generate new results. +application definition. This results file and the reconstruction is +imported by the spatial statistics tool which again keeps track of all files. -We are convinced that defining, documenting, using, and sharing application definitions -is useful and future-proof strategy for software development and data analyses as it enables -automated provenance tracking which happens silently in the background. +This design makes it possible to rigorously trace which numerical results +were achieved with a specific input and settings using specifically-versioned tools. -Base classes have been defined to group common pieces of information for each tool of the -toolbox. For each tool we define a pair of base classes. One for the configuration (input) side -and one for the results (output) side: +We understand that this additional handling of metadata and provenance tracking +may not be at first glance super relevant for scientists or appears to be an +unnecessarily complex feature. There is indeed an additional layer of work which +came with the development and maintenance of this functionality. - :ref:`NXapm_paraprobe_tool_config`, :ref:`NXapm_paraprobe_tool_results`, :ref:`NXapm_paraprobe_tool_common`: - Configuration, results, and common parts respectively useful for the application definitions for tools of the paraprobe-toolbox. +However, we are convinced that this is the preferred way of performing software +development and data analyses as it enables users to take advantage of a completely +automated provenance tracking which happens silently in the background. .. _ApmParaprobeAppDef: Application Definitions ####################### -NXapm_paraprobe application definitions are in fact pairs of application definitions. -One for the configuration (input) side and one for the results (output) side. For each -tool one such pair is proposed: +Application definitions for the input side (configuration) of each tool were defined. - :ref:`NXapm_paraprobe_transcoder_config`, :ref:`NXapm_paraprobe_transcoder_results`: - Configuration and the results respectively of the paraprobe-transcoder tool. - Load POS, ePOS, APSuite APT, RRNG, RNG, and NeXus NXapm files. - Store reconstructed positions, ions, and charge states. + :ref:`NXapm_paraprobe_config_transcoder`: + Configuration of paraprobe-transcoder + Load POS, ePOS, APSuite APT, RRNG, RNG, and NXapm HDF5 files. - :ref:`NXapm_paraprobe_ranger_config`, :ref:`NXapm_paraprobe_ranger_results`: - Configuration and results respectively of the paraprobe-ranger tool. + :ref:`NXapm_paraprobe_config_ranger`: + Configuration of paraprobe-ranger Apply ranging definitions and explore possible molecular ions. - Store applied ranging definitions and combinatorial analyses of possible iontypes. - :ref:`NXapm_paraprobe_selector_config`, :ref:`NXapm_paraprobe_selector_results`: - Configuration and results respectively of the paraprobe-selector tool. + :ref:`NXapm_paraprobe_config_selector`: + Configuration of paraprobe-selector Defining complex spatial regions-of-interest to filter reconstructed datasets. + + :ref:`NXapm_paraprobe_config_surfacer`: + Configuration of paraprobe-surfacer + Create a model for the edge of a point cloud via convex hulls, alpha shapes. + + :ref:`NXapm_paraprobe_config_distancer`: + Configuration of paraprobe-distancer + Compute analytical distances between ions to a set of triangles. + + :ref:`NXapm_paraprobe_config_tessellator`: + Configuration of paraprobe-tessellator + Compute Voronoi cells for if desired all ions in a dataset. + + :ref:`NXapm_paraprobe_config_nanochem`: + Configuration of paraprobe-nanochem + Compute delocalization, iso-surfaces, analyze 3D objects, and composition profiles. + + :ref:`NXapm_paraprobe_config_intersector`: + Configuration of paraprobe-intersector + Assess intersections and proximity of 3D triangulated surface meshes in + continuum space to study the effect the parameterization of surface + extraction algorithms on the resulting shape, spatial arrangement, + and colocation of 3D objects via graph-based techniques. + + :ref:`NXapm_paraprobe_config_spatstat`: + Configuration of paraprobe-spatstat + Spatial statistics on the entire or selected regions of the reconstructed dataset. + + :ref:`NXapm_paraprobe_config_clusterer`: + Configuration of paraprobe-clusterer + Import cluster analysis results of IVAS/APSuite and perform clustering + analyses in a Python ecosystem. + +Application definitions for the output side (results) of each tool were defined. + + :ref:`NXapm_paraprobe_results_transcoder`: + Results of paraprobe-transcoder + Store reconstructed positions, ions, and charge states. + + :ref:`NXapm_paraprobe_results_ranger`: + Results of paraprobe-ranger + Store applied ranging definitions and combinatorial analyses of all possible iontypes. + + :ref:`NXapm_paraprobe_results_selector`: + Results of paraprobe-selector Store which points are inside or on the boundary of complex spatial regions-of-interest. - :ref:`NXapm_paraprobe_surfacer_config`, :ref:`NXapm_paraprobe_surfacer_results`: - Configuration and results respectively of the paraprobe-surfacer tool. - Create a model for the edge of a point cloud via convex hulls, alpha shapes, or alpha-wrappings. + :ref:`NXapm_paraprobe_results_surfacer`: + Results of paraprobe-surfacer Store triangulated surface meshes of models for the edge of a dataset. - :ref:`NXapm_paraprobe_distancer_config`, :ref:`NXapm_paraprobe_distancer_results`: - Configuration and results respectively of the paraprobe-distancer tool. - Compute and store analytical distances between ions to a set of triangles. + :ref:`NXapm_paraprobe_results_distancer`: + Results of paraprobe-distancer + Store analytical distances between ions to a set of triangles. - :ref:`NXapm_paraprobe_tessellator_config`, :ref:`NXapm_paraprobe_tessellator_results`: - Configuration and results respectively of the paraprobe-tessellator tool. - Compute and store Voronoi cells and properties of these for all ions in a dataset. + :ref:`NXapm_paraprobe_results_tessellator`: + Results of paraprobe-tessellator + Store volume of all Voronoi cells about each ion in the dataset. - :ref:`NXapm_paraprobe_spatstat_config`, :ref:`NXapm_paraprobe_spatstat_results`: - Configuration and results respectively of the paraprobe-spatstat tool. - Compute spatial statistics on the entire or selected regions of the reconstructed dataset. + :ref:`NXapm_paraprobe_results_nanochem`: + Results of paraprobe-nanochem + Store all results of delocalization, isosurface, and interface detection algorithms, + store all extracted triangulated surface meshes of found microstructural features, + store composition profiles and corresponding geometric primitives (ROIs). - :ref:`NXapm_paraprobe_clusterer_config`, :ref:`NXapm_paraprobe_clusterer_results`: - Configuration and results resepctively of the paraprobe-clusterer tool. - Compute cluster analyses with established machine learning algorithms using CPU or GPUs. + :ref:`NXapm_paraprobe_results_intersector`: + Results of paraprobe-intersector + Store graph of microstructural features and relations/link identified between them. - :ref:`NXapm_paraprobe_nanochem_config`, :ref:`NXapm_paraprobe_nanochem_results`: - Configuration and results resepctively of the paraprobe-nanochem tool. - Compute delocalization, iso-surfaces, analyze 3D objects, composition profiles, and mesh interfaces. + :ref:`NXapm_paraprobe_results_spatstat`: + Results of paraprobe-spatstat + Store spatial correlation functions. - :ref:`NXapm_paraprobe_intersector_config`, :ref:`NXapm_paraprobe_intersector_results`: - Configuration and results resepctively of the paraprobe-intersector tool. - Analyze volumetric intersections and proximity of 3D objects discretized as triangulated surface meshes - in continuum space to study the effect the parameterization of surface extraction algorithms on the resulting shape, - spatial arrangement, and colocation of 3D objects via graph-based techniques. + :ref:`NXapm_paraprobe_results_clusterer`: + Results of paraprobe-clusterer + Store results of cluster analyses. -.. _ApmGermanNfdi: +.. _ApmParaprobeNewBC: -Joint work German NFDI consortia NFDI-MatWerk and FAIRmat -####################################################################### +Base Classes +############ + +We envision that the above-mentioned definitions can be useful not only to take +inspiration for other software tools in the field of atom probe but also to support +a discussion towards a stronger standardization of the vocabulary used. +Therefore, we are happy for comments and suggestions. + +The majority of data analyses in atom probe use a common set of operations and +conditions on the input data even though this might not be immediately evident +or might not have been so explicitly communicated in the literature. +Some tools have a specific scope because of which algorithms are hardcoded +to work for specific material systems. A typical example is a ranging tool +which exploits that all the examples it is used for apply to a specific material +and thus specific iontypes can be hardcoded. + +Instead, we are convinced it is better to follow a more generalized approach. +The following base classes and the above application definitions present examples +how one can use NeXus for this. + + :ref:`NXapm_input_reconstruction`: + A description from which file the reconstructed ion positions are imported. + + :ref:`NXapm_input_ranging`: + A description from which file the ranging definitions are imported. + The design of the ranging definitions is, thanks to :ref:`NXion`, so + general that all possible nuclids can be considered, be they observationally + stable, be they radioactive or transuranium nuclids. -Members of the NFDI-MatWerk and the FAIRmat consortium of the German National Research Data Infrastructure -are working together within the Infrastructure Use Case IUC09 of the NFDI-MatWerk project to work on examples -how software tools in both consortia become better documented and interoperable to use. Within this project, -we have also added the `CompositionSpace tool that has been developed at the Max-Planck-Institut für Eisenforschung -GmbH in Düsseldorf `_ by A. Saxena et al. +A detailed inspection of spatial and other type of filters frequently used in +analysis of atom probe data revealed that it is better to define atom-probe-agnostic, +i.e. more general filters: -Specifically, within the IUC09 we refactored the code base behind the publication `A. Saxena et al. `_ to better document its configuration, here as an example implemented like for the above-mentioned paraprobe-toolbox using NeXus: - - :ref:`NXapm_compositionspace_config`, :ref:`NXapm_compositionspace_results`: - Configuration and the results respectively of the CompositionSpace tool. + :ref:`NXspatial_filter`: + A proposal how a point cloud can be spatially filtered in a specific yet general manner. + This base class takes advantage of :ref:`NXcg_ellipsoid_set`, :ref:`NXcg_cylinder_set`, + and :ref:`NXcg_hexahedron_set` to cater for all of the most commonly used + geometric primitives in atom probe. + + :ref:`NXsubsampling_filter`: + A proposal for a filter that can also be used for specifying how entries + like ions can be filtered via sub-sampling. + + :ref:`NXmatch_filter`: + A proposal for a filter that can also be used for specifying how entries + like ions can be filtered based on their type (ion species) + or hit multiplicity. diff --git a/manual/source/classes/contributed_definitions/cgms-structure.rst b/manual/source/classes/contributed_definitions/cgms-structure.rst index 53f57dc8c..6190f0a30 100644 --- a/manual/source/classes/contributed_definitions/cgms-structure.rst +++ b/manual/source/classes/contributed_definitions/cgms-structure.rst @@ -1,14 +1,15 @@ .. _CgmsFeatures-Structure: -============================ -Geometry and microstructures -============================ +========================= +Geometry & Microstructure +========================= .. index:: IntroductionCgms PhysicsCgms CgmsAppDef CgmsBC + IcmeMsModels .. _IntroductionCgms: @@ -19,23 +20,30 @@ Introduction The computational-geometry/microstructure-modeling-based part of the proposal has the following aims: -First, to contribute to efforts on standardizing a controlled vocabulary, definitions for terms, -and relations between terms, for computational-geometry-based descriptions of the structure of -materials and atomic configurations used when characterizing materials in experiments +First, we would like to contribute to efforts on standardizing a controlled +vocabulary, definitions for these terms, and relations between the terms, for +computational-geometry-based descriptions of the structure of materials and +atomic configurations used when characterizing materials in experiments and computer simulations. -As far as NeXus is concerned, this proposed set of geometric primitives offer -a complementary alternative to the current set of base classes in NeXus for -constructive solid geometry (CSG) such as :ref:`NXcsg`, :ref:`NXoff_geometry`, or :ref:`NXquadric`. +As far as NeXus is concerned, this proposed set of simple geometric primitives +and shapes offer a complementary alternative to the current set of base classes in +NeXus for constructive solid geometry such as :ref:`NXcsg`, :ref:`NXoff_geometry`, +or :ref:`NXquadric` to name but a few. -Second, to explore how terms which are frequently used by materials scientists in the field of -condensed-matter physics can be harmonized with definitions and terms offer by the NOMAD MetaInfo -description. NOMAD MetaInfo is the data schema of the NOMAD research data management system. +Second, we would like to explore with this proposal how we can harmonize terms +frequently used by materials scientists in the field of condensed-matter physics +with definitions and terms offer by the NOMAD MetaInfo description. -Third, to yield a substantiated set of arguments and suggestions how descriptors for the structure -and the atomic architecture of materials can be harmonized. Especially this proposal reaches out to -other materials-science-related projects and consortia including the activities in the German NFDI -FAIRmat, NFDI-MatWerk, NFDI4Ing, NFDI4Chem, NFDI4Cat, MaRDI, and DAPHNE. +Third, the proposal should yield a substantiated set of arguments and suggestions +how descriptors for the structure and atomic architecture of materials can be +harmonized. With this we especially would like to reach out and intensify the +cooperation between the materials-science-related consortia of the German +National Research Infrastructure, specifically, FAIRmat, NFDI-MatWerk, NFDI4Ing, +NFDI4Chem, NFDI4Cat, MaRDi, and DAPHNE. + +.. The proposal reaches out to our colleagues in the materials engineering-based +.. consortia to document that there is value in discussing about controlled vocabulary. .. _PhysicsCgms: @@ -43,37 +51,47 @@ Physics background ################## Microstructural features or crystal defects are spatial arrangements of atoms. Given their specific atomic arrangement and composition, such features have -specific constraints on the degrees of freedom. This causes these defects to have specific -properties (thermodynamic observables/descriptors). Provided well-defined coarse-graining procedures -are used and regions-of-interest and/or regions-of-applicability are defined, microstructural -features are often characterized and modelled to have associated thermodynamic descriptors. +specific constraints on the degrees of freedom how atoms can arrange. This causes +these defects to have specific properties. +Provided well-defined coarse-graining procedures are used and regions-of-interest +and/or regions-of-applicability are defined, microstructural features are often +characterized and modelled to have associated thermodynamic descriptors. Another motivation for the proposal was the observation that frequently the design of file formats for simulation software in the computational materials science especially -at the interface between condensed-matter physics and materials engineering are frequently -reimplementing the wheel when it comes to making decision how to store e.g. atom and feature positions -or how to document the shape of regions-of-interest, grids, crystals, grains, precipitates, and dislocations. -This generates a diversity of file formats and data schemas which hampers semantic interpretation -and interoperability. - -Maybe this is a historical burden given the large set of technical terms in place which then -motivated pragmatic solutions that have resulted in many research groups having developed -similar formats using similar descriptions. - -Defining crystal defects is a question of how to coarse-grain a given spatiotemporal set of atoms, -each having a nuclide type and position/trajectory. Different mathematical/geometrical methods exists -to determine how a point, a line, a surface, or a volumetric defect can be described and be spatiotemporally constrained through a geometrical model -with defined primitives and associated observables. - -The key motivation to such coarse-graining is to reduce the complexity of the description. -On the one hand to support visualization and scientific analyses - not only of crystal defect arrangements. -On the other hand it is the hope that using descriptors at a coarser level, i.e. nanometer, micrometer, and larger, -are still sufficiently accurate and precise to yield descriptors which avoid that one has -to account for the dynamics of each atom to predict or understand the properties -of defects and their dynamics. - -Experience has shown that computational-geometry-based descriptions -when combined with hierarchical clustering/labeling methods, applied on sets of +those tools at the interface between condensed-matter physics and materials engineering +are frequently reimplementing the wheel (at least partly) when it comes to decide how to store +e.g. atom and feature positions or shape of regions-of-interest, grids, crystals, +grains, precipitates, and dislocations. + +Maybe this is a historical burden given the large set of technical terms and jargon +in place, which then motivated pragmatic solutions that resulted in many research groups +have developed similar formats using similar descriptions. + +We see this work on base classes and application definitions not primarily an +effort to improve and extend NeXus for now. Rather this part of the proposal +is an effort to support activities in materials science to work towards +common terminology and using controlled vocabularies more frequently. +These are the foundation for more sophisticated thoughts about practically +useful ontologies. + +Defining crystal defects is a question of how to coarse-grain a given spatiotemporal +set of atoms, each having a nuclide type and position/trajectory. Different mathematical/geometrical +methods exists to coarse-grain and thus determine how a point, a line, a surface, or +a volumetric defect can be described and be spatiotemporally constrained through +a geometrical model with defined geometric primitives and associated (materials) +properties at a coarser-scale. + +The key motivation to such coarse-graining is to reduce the complexity of the +description. On the one hand to support visualization and scientific analyses - not only +of crystal defect arrangements. On the other hand it is the hope that using descriptors +at a coarser level, i.e. nanometre, micrometre, and larger, it is still possible +to find sufficiently accurate and precise descriptors that avoid one having to account +for the dynamics of each atom to predict or understand the properties of defects +and their dynamics. + +Nevertheless, experience has shown that computational-geometry-based descriptions +when combined with hierarchical clustering/labeling methods, applied on set of atoms and features turn out to yield useful descriptors. Examples include point, line, surface defects, such as vacancies, solute cluster, dislocations, disconnections, interfaces to name but a few. @@ -83,125 +101,184 @@ disconnections, interfaces to name but a few. Base Classes ############ -The following base classes are defined to incentivize the use of NeXus for using -computational-geometry-based descriptions. In what follows, base classes +The following base classes are defined to incentivize the use of NeXus for +using computational-geometry-based descriptions. In what follows, base classes for frequently used shapes and geometric primitives are proposed: - :ref:`NXcg_primitive_set`: - A base class to inherit from when defining base classes for specific primitives such as these: - :ref:`NXcg_sphere_set`: - A base class for a set of possibly dissimilar spheres. + A description for a set of possibly dissimilar spheres. :ref:`NXcg_ellipsoid_set`: - A base class for a set of possibly dissimilar rotated ellipsoids. + A description for a set of possibly dissimilar oriented ellipsoids. :ref:`NXcg_cylinder_set`: - A base class for a set of possibly dissimilar rotated cylinders. + A description for a set of possibly dissimilar oriented cylinders. :ref:`NXcg_point_set`: - A base class for a collection of points with labels or mark data. + A collection of points with labels. :ref:`NXcg_polyline_set`: - A base class for a collection of lines and linearized segments. + A collection of lines and linear segments. :ref:`NXcg_triangle_set`: - A base class for a collection (or soup) of triangles. + A collection of triangles. :ref:`NXcg_parallelogram_set`: - A base class for a collection of possibly dissimilar parallelograms. + A collection of possibly dissimilar parallelograms. :ref:`NXcg_triangulated_surface_mesh`: - A base class for a collection and/or mesh of triangles. + A mesh of triangles. :ref:`NXcg_polygon_set`: - A base class for a collection (or soup) of polygons. + A collection of polygons. :ref:`NXcg_polyhedron_set`: - A base class for a collection (or soup) of polyhedra. + A collection of polyhedra. :ref:`NXcg_roi_set`: A container to host a number of different types of primitives. :ref:`NXcg_tetrahedron_set`: - A base class for a collection (or soup) of tetrahedra. + A collection of tetrahedra. :ref:`NXcg_hexahedron_set`: - A base class for a collection (or soup) of hexahedra to represent - e.g. simpler (bounding) boxes for e.g. binary trees. + A collection of hexahedra with capabilities to represent + also simpler (bounding) boxes for e.g. binary trees. -These base classes make use of base classes which describe data structures: +These base classes describe data structures used for more complex geometries: :ref:`NXcg_face_list_data_structure`: - A base class to store the usual way how polygon/polyhedra data are reported: - Via a list of vertices and faces with identifiers and properties. + In essence, the usual way how polygon/polyhedra data are reported: + A list of vertices and faces with identifier and properties. :ref:`NXcg_half_edge_data_structure`: - A base class for more advanced but more efficiently traversable data structure: - A half-edge data structure is a useful complementary descriptor for - polygon/polyhedra which enables topological analyses and traversal of half-edges - about a topology of primitives. + A half-edge data structure (also known as a doubly connected edge list) + is a useful complementary descriptor for polygon/polyhedra which enables + topological analyses and traversal of the graph of how polygons and + polyhedra are connected. :ref:`NXcg_unit_normal_set`: - A base class for storing primitive unit normal vectors. + As an additional structuring element especially for meshes, well-documented + normal information is crucial for distance computations. :ref:`NXcg_geodesic_mesh`: - Geodesic meshes are useful for all applications when meshing the surface of a sphere - with many applications in the analyses of diffraction data. + Geodesic meshes are useful for all applications when meshing the surface + of a sphere. :ref:`NXcg_alpha_complex`: Alpha shapes and alpha wrappings, specifically the special case of the convex hull, are frequently used geometrical models for describing a boundary or edge to a set of geometric primitives. -Furthermore, a few base classes are defined for documenting the working with -discretized representations of material (area or volume) which can be useful -not only for stencil-based methods: +Next, a few base classes are defined for documenting discretized representations +of material (area or volume) which can be useful not only for stencil-based methods: :ref:`NXcg_grid`: - A base class for a grid of cells discretizing e.g. a computational domain - or computation with models using representative volume elements (RVEs). + A grid of cells. :ref:`NXisocontour`: - A base class for isocontour descriptions. + A description for isocontour descriptions. :ref:`NXcg_marching_cubes`: - A base class to store metadata of a specific implementation of + An approach to store metadata of a specific implementation of the Marching Cubes algorithm, whose sensitivity to specific topological - configurations is known to result in different triangle soups. - This is relevant e.g. for computations of isocontours. + configurations is known to result in different triangle collections. :ref:`NXdelocalization`: - A base class to document procedures whereby a scalar field - is smoothened in a controlled manner (typically using kernel methods). + An approach to document procedures whereby a scalar field + is smoothed in a controlled manner. :ref:`NXsimilarity_grouping`: - A base class to describe clustering of objects (such as atoms or features). + An alternative for NXclustering. + + :ref:`NXclustering`: + A description for clustering of objects (such as atoms or features). + + :ref:`NXorientation_set`: + A set of parameters to describe the relative orientation of members of a set of features/objects. + + :ref:`NXslip_system_set`: + Metadata for a set of slip systems in a given crystal structure. - :ref:`NXrotation_set`: - A base class to describe the relative orientation or rotation members - of a set of features/objects. + :ref:`NXms_feature_set`: + Generic base class to describe any nested set of features + of a microstructure at the continuum-, micron-, nano-scale, or + to represent a topology of molecules and atoms. + + :ref:`NXms_snapshot`: + A container to describe the state of microstructural features + at a given point in time. + + :ref:`NXms_snapshot_set`: + The corresponding class to hold a set of :ref:`NXms_snapshot` objects. :ref:`NXchemical_composition`: - A base class to document (chemical) composition of a sample or a set of things. + (Chemical) composition of a sample or a set of things. -Finally, the following base classes allow data processing software to document its -input parameters and to summarize its performance statistics: +Finally, the following base classes allow data processing software to document its input +parameters and to summarize its performance statistics: :ref:`NXprogram`: - A base class for a specifically named and versioned program or library/component. + A named and version of a program of library/component. :ref:`NXcs_filter_boolean_mask`: - A base class for a boolean mask. + A boolean mask. :ref:`NXcs_prng`: - A base class for settings of a pseudo-random number generator (PRNG) algorithm. + Metadata of a pseudo-random number generator (PRNG) algorithm. :ref:`NXcs_profiling`: - A base class for holding a set of :ref:`NXcs_profiling_event` instances. + A structuring group holding a set of :ref:`NXcs_profiling_event` instances. :ref:`NXcs_profiling_event`: - A base class for documenting profiling/benchmark for an algorithm or computational step. + Profiling/benchmark data to an event of + tracking an algorithm/computational step. :ref:`NXcs_computer`: - Base class for describing a computer and its components. \ No newline at end of file + Metadata of a computer. + + :ref:`NXcs_cpu`: + Metadata of a central processing unit. + + :ref:`NXcs_gpu`: + Metadata of a graphical processing unit / accelerator. + + :ref:`NXcs_mm_sys`: + Metadata of the (main) memory (sub-)system. + + :ref:`NXcs_io_sys`: + Metadata of the input/output system. + + :ref:`NXcs_io_obj`: + Metadata of a component storing data of an :ref:`NXcs_io_sys` instance. + +.. _IcmeMsModels: + +Application definitions for ICME models +####################################### + +It is important to embrace the large research community of materials engineers +as they are frequent users of electron microscopy and atom probe microscopy. +In this community frequently ICME (Integrated Computational Materials Engineering) +microstructure models are used. These models are derived from a design strategy +and workflow whereby physics-based modelling of microstructure evolution, typically +at the mesoscopic scale, is used to understand the relations between +the microstructure and technological relevant descriptors for the properties +of materials. + +The following application definitions are proposed to support discussion on +how materials engineering-specific data models connect to or can be mapped on +concepts which are equally modellable with NeXus: + + :ref:`NXms`: + An application definition for arbitrary spatiotemporally resolved simulations. + + :ref:`NXms_score_config`: + A specific example of how :ref:`NXapm_paraprobe_config_ranger` can be + specialized for documenting the configuration of a computer simulation + with the static recrystallization cellular automata model SCORE. + + :ref:`NXms_score_results`: + A specific example of how :ref:`NXms` can be specialized for documenting + results of computer simulations with the static recrystallization + cellular automata model SCORE. diff --git a/manual/source/classes/contributed_definitions/container/ComplexContainerBeampath.png b/manual/source/classes/contributed_definitions/container/ComplexContainerBeampath.png deleted file mode 100644 index 597cee834c0426bd0e60b1afbf6554a5f3b04a99..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 7089 zcmbVxgT!j8lW(I7CP9R3l4E<2>J5 z)AI_IpP{<#g$8#av2ACx&qHz?7*6{wc9+~vb1nw=8zsvCGZ@1U!ma35{YCTeb^go#}G;SGXdmMbu z&k(dLz+>M0rk*>Sf)`6r0rqXS-WdWA6B8%4ZJE%EdqQPyjwzkRB;aOHTl>4)o5x|d zk^nCj4;eIl%(n^F+aGp�Z2d70QK#NZGhGGt4!*DVv+aK@%#_`tEYYN5riu(%l4#$J*D7^Wj?wMl{e?}qh~ zY>s%K&(C)zD>TXgDhM0}O&=C2r+yy#K3pp3G_SZgw*E;r78oa{=-eoZRr2X4M1X%T zpwKhuUnefLT1P?+p*cUDbF;27;urNXIdV3GP9r`-Tm1Iz!5axr2q&_2aKHv)6R*sV zoC86Z4ZQcMBBg7vGph*EBH-3c92|H`VKT=wJcAF`QUTL~RppiMF@&7l+%|jh=q_Yl zl(4Ai%5;s*CbbwAZH2$YiG@Y5cQ^ujWfjnl_}!#bRb1n>F}OTlrVE!&9&uFk^!!4^ z;FHzbDye5^Xk#UxwXh=zxB3+h)q$p^rRmjVynV~|G~Rjyp=(MM0mu_vg>= zxp&taB#b47RTc~^Sn`WBaGB9RJ~<@SMf)iaypK+F>MgC7zsG<%r}Pqabh%S?=ZlnO z^3i`NU#PHfxzukcD5suN`yh?Xm0-C9poTO!`bZon&_&qD+`{Bx!n8>beH987Qkx%6 zRNOt{;*|T%y-h7HKpqjqJ|6|a$DY4jlDeCYdZAn2&+t{t*H<)>RWW_m=_B!yXoyoi~j%|VXyXk z04CaDLB0Woc^Km9>6tgSGvc<^MsnrPilHHjLv>{cIk;b)x=dF3^O!*;WI(#z7`=S_P(B*fsh&^#>LCqbFwo<4%S1-m5+rtCdO_86H82|ZC-J$ z^0QbYQ`^F#vI*`-R!K??acY7!^%XsR4*+eK%Hj)EVh@1o1ZacHTr3XZeXE%-cJZ^~ z?igTnbhO%Wgc-Tl^we?eguId(P0owu>bd@t3XpYIWGuOgQ3;QMy?OJ-3M_sY35mfq zuL>o*x~!TS!N0WzGR3%G{DKF@zLYPS60_t>W-)`#e=IG9h1bEVcPafZw@P#@ERv6p zy`y8B4KrpKCaWw_2M6wwSG%=MfhV6$c;?N^>W7f6Z-J zDZ9VEuFcES$qeV@;ra2!?iU#qRgB+afU-yn!0$B5%45;`0FQ+Jpvg1>NBLMTz?jA| z)(osl*JpZq(Vf!EzRs{Z#ZpRbFK?ztkBILl;4p?=3tZpa=+|-|^w7C6v9sgywH;Fs z5D@4!^2MZlIShqt{M-5$5}9@b3BTNuH88kO!XO#foj}bZFw%z41MhYee!kk11Oklz z`dh>Fa}3e4#Q&K^U0w$2y?M`4s?}sm*A~AeYh%N5dpXtdeQ1dE*Lyz0`5f+^M4G6z zHCqtGR@VAntA~)o{%h9k?(R;MI#dUbIHEcyL@Z3EPxQq*VzL9^&^mv_@!);Obxb`s0N9NAtehd-L8uV}6C42C7z=Ib>PI6$H_DA_up%NN{Fh^> z@6}Hj#FD_{!Tfx_zu5NJ|A5Ka53{$5E!*l!AM|fiPAus(m+^;m79F8dyynf(?=1rH zL1Z)>HwZHN>dAH-*ru$A9m`(xn;An7#+IpHMW`trs;7o`dodKo%*qNKlD;Z0@SS}M zHU)v8)BotDgVO^R+R17TGolBVnK8I7s(9m@l)VE3NI5x(eSbQnP-m9fpg%(h52&{L zb-y_Dz`Ik#*O}nHg zNlM)8!9#x}(&v1I@WQ?csp#Kj<(@;5C9WOi9N+_lr(szFV>MwNGCcRs0*lZ|JIVP9 zA=!WCs+T1Mg;0=m61V*fl8wT){%kq|Mn?2fwDZ(fo$MHgwK`?lUyM`_1(0Ukfxp`(RR^z-IUr-0Hi-PWow{Cu;JB3(UcuYs*w zS4*6aR_LvhhkwGVo|nTL3j)wU85OH)F@&*_VhEf6T494$f9%^o{wW)R-E2MjvGeza zFSC{4jJ5&0C5fpaM@X8+x{0vKT$s9P6dx_!2}!7${-?<)v7eVYfycvLXmo&twy8~2 zSzgxcRWV?%+mDKmCxGJOHY}zf zBEzVtsQQD4x4pr}DhW>kTOQr`_F+|Id_uJWpE4krDs1n$j^ z4~#^#*Vo<6%_-@S^o6&xx9o;ptbyqcres_rlnA$?e4mR+7B4CynP7Ygfwge$eLz}V zGHzyvt(_DOG`TG4bC_tSFx*_?tgdwH@@G^c9{#)#bZ|j__6fymYZZ3A(t^oZFRLDJ z<|7pqNdZ|D!)U?g&d%b-{%;MSR7p(6^ymT)h)QkekSh-{N&J1hTjn*>H)-(^OFEn3 zfYf#FlAvDXSZH;}`L!fzojkUZ-u6h1~<|ldl38{cs(Tz z^yf0hlCvn;jF)zoekSZnWBb{^yuUDabL6)Zuf3|k>+R2D zMvZ^Gh-lu&y-J9rKP7y=AV`reWqLvN9_W;5A}8f@GEIFJ>MP(|aY1j>ljymVg<{x4 zjTFww#AKCVyAHqe?wr(PU0Yvgn<*~*(cO)Zkf1efbUo?C5fXKog#!N9hvflQ_Ei@1S=cn*o&~0NkFVWeV!*?(Mf@_YaIXRWBoSN8N{9R{?_E)?I0Pl)- zSk3-lc6VCwGx2l6)(wj|_KY$|AtH*hpC?w_!mj9Eym)c1V@Ac9UMldOv9Ym=hDLYW znZ#o0TO2BlDK1H~Tb&O}SYUmu{fUFUp;BFPRH*QlWfB*sA(cD;7K8SsKm<0T%Jh2< zl25-sW)G5-%1!FyUy%-yRq84#LT$7pDM1{kASaKA|J*&W{>_j1Bet3!Q3ERr3${`r zxt8<=t9tQd$(x@834HBwAge03Xrmn&8TmB#UY;zXJtTXHv-mT3HX4_wdxXvk*q_u~ zB^KOt1>j_xQ&o(Mfjf`PTK&m~q|UNl_(H6f+C%*J+s^o{zeB+URn(uW&@u3)lKb|J z;p;&>2N*w%=;1HNUykTZO0!8|{kbxXs;a8Jy}g~u@F#jT#yUC?U%fU8K$QTFg)4oE z%_J{+UxjhaAyD}a+Cs@wwyCv08}-sKhMprLBO|M=zF~n3htt&!q@|o7$!ghePmm7z z=+^r^QYn-8Z8ux1OeYQ)J;h$WBE@i|1QQu8Z9J*;IbdgJ7r&Ia))|34-QYs^?AbGZ z=Sd!<%U1ubM*O7q$3I697l{b1@r}c zb#YGrIZ^e>4+;7>IyR=G?@1{o-#w>byhE2awIfv-SjnB5>qWm1bS$f`p7=skW1XFT zab*!&nTEAa*pl^45h`few>x}ywmtEbT}whUI9L)~CN=kUf=-|A2g^ng;RDWaM3N{S zftMEMw&v9*0uNO={Kbrmkq%3Z5NXTI?3koyUB@P}H98^f}=x3TKl?q2}O2mR_|A|nL zG%`hFHXWWohRc4KLB~t}UJ|dtfA+lL(mfBsorQsVS4B-NvMQG`*|mrnY;qfg*hFN{ zAVt)=7mvOnW!V#zSZ;&1_0}9V3d%PhmV*IWUO1bT7+5{`@uWt=L$Aen^UF!p7wjLOt42~RsEI<~v438pG3D_0z4+^UFEz|`) zvuD@Lii^O;!@>~8S9gxNMoiLx4hhjF6<`Q53Q7mdctdkR2MJQ(Hb3194@9I}(Z6jDB zJ-!i-Y^d~bBcC&hzN{R&7{>TGfa3hb5Hl;n^pGGf31?*`JccmBb>U5|n<%zhE5z0o zFs#D*K1$Z!-dX3=Ia(A>%e}X|NL+4)pCwH^KJlswMT6a+iTAMxVxlBhGDD=E4w!Xl zR`oTwY|rFK!#R0fgRZJNaIvu794Qm5yb=~B`#Y=?lD|D9mB+$H zGGJ}T z>oxbA*&q6uHWjLhk7x@@K%-tEY!@WtNf=nyYKLH|PiyahN^|b2kcg7p`!3!)O1;1M zD8B@WA@E4Zz66RO5QvrA8XNqw&$>ONTwlKIRz-bacHh*#f`TAOsjnZcp1tkwDX9tt zZ{qN8LFksZFmv_H?%aH{-5m}-3H#ct$VIS<=6#fu9l;H<{q^2lw`hBNw4T9Fhg>pw z-#_9?|jjKcL2)~hIOYm38(_cRw(@DuF$S@N9u3V*z!Az)-2&b_hHdUq^ z3xAG=x_$BS|6XF^xpYf4D&8f*`ZGCZZ*GH5cAFtri0_{bBW7wN&i!X;U;vBKFoUaB z6dC4ff2%rVim5w%$osJCH6|G^oQf{XGA&-h3Vz9;(IbvVh*_!@a$6 zyTloD+(iBw#EpzJ3i{pq)k`)&d?7g=D>&G!kx|lUUOLEtfpK)Sl+m;S2)lf}(;y}2HdDyC+iQAu1*gEi}#v~#)tauKr>f77x zt6>sJhdB3RN6g7o#Nn!O5c2@$o2<(txGSh4PEM)$;^+L99-&Aj;AE5vj1>sQN8#5B zF>QemN{)ubKP~$|T#CZT>1e}^Yd5Ps9XV5SNamaJ%QYO<)?X+s!HDn+>w zgkDCoQRbQqMq)6TbMKLEM=HzKk<4|35{?o}k|!F4XAzn)`Jp=2rzD#7Y<@KZ9_6xr z9pG^flGkOg=6S@9K%*$XI8h=F4-3p?WM;QM;o1v@ECrnoCksU7yJVMox*z0C<2SkI zpI;8id|nc0`Y*%L>%eNNE3z$!^6!M<_Bk7b8p6h(>7>O`A0 z<+Zv*G%oobe{*ED{dM1NZ?PGvV#``j4cAc7NNPgGz!Dkv{TaS@;b(}yo^=0#PGFJz zZnL536YPaW4f$FI*7aZ8k+WfKpLp58WA|%}Q@wZTZb|N&MlBd(NM`?fsxmB0elg5a zyhTfzYtn^Y>O}{*Xk9rgF>z5nn_pVy(}ezLUu)}VJ-yP^B{+!VuV+ohkm{K0X1(jcKbDH?b&>a_(vxDPrweFG!4ZAQaM@IzzoNjj}rA zDd{kJNtN8Ib6~C!yRUCI`0r^kQiz=V_+lWl4sGU=mKMH|Lz&xg`au%S7JWZM-(ZyC zY#>w0b+bZ4{R69Ou8h`8GW{N}ZKwn{hbDlMWY(nFn;@L7Cww3hUttM6+E&%TSqy$H zO&vQlZoeprsc76h-5UFw_||P67JNj!psA8~0(<040j;#8ZhWd1PAZ)@XY#1pN)8>I z64k46S?F;kD#aHQ)0rptsTt&LEW5MFr}iV=DwtlH#MuJc^?~}{NW{(*GKiKKp`5JJSn=tL zWw`ym#rh3c5D}+>zU7-!QKX}9Q^r3wOy16eEhKnz|J>v1gl6sbZ`IcmKef_PdcMtKNSG<9Xx4}|=|E$9hEynSWZfFpV5_G*B%drKT zf{p37pZB$gbas&@46(47YZbb@8iCPEJw!2f+^TU{;OoX*ofcVd4Ci}K&W{udOOZ=t z#S%e0z1B4hVGwq$;tgot*W3B8oi}G=XMrnFctcBY#-FJdPMc3$vx24TVrm__`JV{r zWa$;L>gx-iP}rwlo)7P^BtBUGJ-T&NRCFAm0y}ZW$gYQY;R;z9O3Hq_ZqLg}D}5gC-$dChBeP#=_&Wpc z6)^{U=SlU}^T*LAGHTrz*Ap~tFkB5b#KBBH*19n!!Q|!N93nX5?j!e>NF|R`ZpIhF zfmx@Ej=QHU&3KG@J$PDno7xgmx2veFAUE;jl8Mo>b>~UIVQ`vsRSAk>_BorqYgesWGUr@`D=W&OA`>A)AQ05o^3v}i5Lh$_1g0Db0lX8X^R58= zdf_PfS`7(&c_EpEf#a8U@*f-_5PbCK9~ip&QWWqep_7c3ld7$mldF+~Da6&)mG!fY zrK7QtohhrW!>5!(VIl~G0`gi~Ld`98f5FvDO??sJ_>&oD^1wR}x|gq!KA*>kW5EVw zuUbm{adpZ^)|#v<)Y9k-VZzhDP{*;_)>cuIo~8+KLbAq6P{#TvKm7Nd=TnVILXyxI zl%HESKB7158}lhreFI-Shi*ud+gI%T>QLF(*pdb}OAZlKLK#?DW!>D|G+hJ3hT`Qk zUH!BpqoSlOEG)n~d3pyk6^H@?0(uLmRDw!Sw1tuBKgK6BpE8`C`NC!=5?;L}APMt; zaR+}E78d4#hJZ*#MU@cM>JN@+jO{4EQ73XtfufD`t#80g8K5T(wmmSFzPQ|niIO#% zUOgN34?|k1wVv~&`)qK;1#&U|SUpzI;H)JFc+BQ?Po4OrOMFz>WFf8o z9?c@2ej~~&m*e?<85w(3)Uwse+1)OJ5mUdcTO9zA|L5vGqJP89V4Q zLZPB^_-L2eM9r>zZP#fA*Ywo1dUUg(N4JSGKmb1D~NPY=dncQ+j0(tM>i z71eHtTc`hR$-q0qBmFFo^&dP6g{;}xe&oJ58oC&mDk$LbTt#kZ%08?1cO#%9_&ha! z=6r>TS=o|>yj!oBigB55F8cCxgpz^-)9q%XWDg%xg|BN_+0eZBF}=T!_U223F&dv=VeyWm~`2Y7bj>l_ksTBB;}*4 z>ovbvbPPNMuVab10~F*RHt0m-_7C7u{h#Nam|r;$`Vz9_J>_!8qVvNhmTZCJc^C9eHBn(jF{TXU6 z?l($^k2k|5du(8~I>BrOzJGatj(yyL-BO_5hBy24PUxp~61hoX@4Ez(1+<<+#b!p43p z8BdoPDYKhnsF1fTi;HMzYZKAFOY%b{=1pDjr_WytMKR6p?dJ8bS?k)$j!QJG(4eesX z6PgCmwT@dZ*IPU0OI~NFi|$)#Xivgd3$Em>_50=ErSy0;2miqUYVn7Zd;qA)nY?!`;cw*oY5aGy9sqo=jkm9DvOR~@huRbmO4pY=SL?N zwlDEmw1Z?K@tmh`_-q%W@>PGkOy7iu{a7RU|6maK?^q;UR|f|S^2I<3A38CgjnzfX zf=y_ziKMr;NV?DMXXX#(KT$lUf}Z179x*)wgM_|*`W)}X#6;RS@f5$B#Q(fyCqIW^ z5HS5JEvMQ({`u=MzhXxrBt*Qkv!gdsIQgGoS_f0Cv3Dw9V6ddPAMQy~@P8o84&)RH zJ@4z52KTcv`?W5O*tr82g6J;R?Rfs@$ewMJ`Sa%scXxNag=k*;ynz1$@jtfY5CR+y zjOA2GaOcO*7d7oG;w~<{|Hj7ZGc`d}2mZ$yPP=$=!?CHUDQz12>VIba##{F9%&VUPR2&MNw#8UcrRPQcZL zn4j+>uW%t_Q9vFL@KtZ2QV~QJX=(4-d{xxvo65?fel%`8Zh=$DKA0>fjtWD<9p7zg zEb)8Z8@H(wg>V0SR>kGyvW&~HbrAJA>4aeoY;W=39op5e{!a+-9@4SJHM+YLq@gX~ z_@v1H@85m=kKKMd3Yh0OaY4kxqhYn69a&VQ9TY@wzvLaCeX!`s_R`2G9SQY7=L~xm z?my?5XZY&Ju;>I$pdq4dr>PUM)wE2R+7a-+n+q4&*L&U$d2*gN8(*etE70QO8Ff9a zk>0<*k4spMjHhm_ud{5#dcKVFTeAvMA=gPtt_nP&Xp*Z%CZ7w#i2~^t@a`0}U4>sf zr}>@@My2|spG|$bp_Yh{kZ1Z&4w_j7`ysnk(j>T}$PZ0CLG1rrj95w39XeMv(Kb8` zr~3Prnr8z2^JgCdvBlqo^|GJXpDz?@+0-2P`#02ek&t!va3gVT`JlL^%xE#;(lv9a z`+25GKX%6mS}p2E4-62QnDHJQu{-5~`^djO*&AT}CtwK7DI3lH>A@YWhW~qp_U%zo z`L~v{Oa30L&l^tAGC0`G#B`#~%yBt4MN(#tSqBd#`CZ=c%u&1ftctH*$1p`aJfto@ z&nH``x>S)pJ=mg_mj}gS(+xoUI;1Q6m+e-9AJb+!$!rg1E6cQ)i^*L1NqUBcWIa6U zex8x|ZW1OTBhS`*Dn8rJc<#-aWBfODxLVz$oMW*kY$r3z&uBt_@rx&&dEWlFD|$ZB zTUY%X?uQRNBYOumkGB}3yh_5DsG)F4+`afdK3;p&yLh{eL$JmfQqYMpE^umQ&lKc}o?D z5U>_18IE(-a%HA(c_0*wZ-R+!kT%NT{*!`?M{*w?DeGBx4kSxtTOT%yAz#gpq37o} z%`f>65e33kzE@R+%NgB1y(uVQ{8XQifR%Wl#)u0G3p?BB>#bmI%>qRT?B8NyVoE!h z_ZAZt5y2$r=^t!VP>9C$y;s>IahYz?n_i+6)j#0m*R>D6UUNFM;zh(k{-Eiaqsq>& z%oK^w*0noPIA>LD(u)NmOUK3;m)Sr|hzpUyUjO6cRkQI#fx2~-=k-eH$#FY+y_cwn z2x$tRtxb2jimTm0WoVgw4#uXpH*S*P1o`LBZI5W&HQqNH z5^hfqKT8fj{sz;Sn7iQ3w2s^U9sEdX1l`W5Y;)P>w)ym zTNYMJs)4jQbWL5%pugN=Q1YP%(xJq57%gTrH;)Jd5dtwEzIU|sXFggr z(!igi(JX|4xbSH*4r{E{;)seu(bi}6Y?(v(XXemt4+ovr0_nkyWZ-1D{Zl{viL z?0&xEi=5GzgE>oJJ7BXDJ@5GfMy8J+8|?O{;j_DSJ&UgyksOAts*Im}L>wHVMs}c| zM5B5Jd6sXs*6fzNi>r^n_xj-*L`jMJAtoen%fET=+W#xRphunnjWnR$B3Pj`v`xVq zDZl8`_m7N$frP*%)I~Ct@Gq0NC>L&kU76@9l!{n50h0{Pc0@ltQveTFeb)32;rysn z@=XMJTf2x}x+=4>6JJ43uIP``(@av)`-Y)Ue949kY={tgDamIqBiR4Pm^PK)sB67< zRbsiMzRe!EJm5gvlQ=|K*%DRXR#x)vFBzbxDb{$5xZzT=4TnV&%Z2$gBBH6SC4c%j ztSc}=K`DV+S?3ycmY1EKT3uLeC2+K?Ty2a<^68C{CnsGvw} zgqWD=^o&2~JqDurB93mv+eQN3yn5_v^6`eZsoN<#YYGj8!XdaBbw!EisjaT`kEw>x zrHAdrHM#ISeIB#BpZNp>p-cBfTXCI-3632W$T*r-RT8lEj3w;{E@&LnY)~-Fwpj#K zyap-?ypKTms0|_=N1d{UnS_hW*aTdfqE@Bdea*{n-x#tTk!cmrJ5M+4hujhE?JelP zd0$yXKYe8wfs#Snv!u-FS!5n_VyTQa`WywPdhrdUFLD)z?y~siK`9~a#9B~L#P2c? zq>|Ghlaay0L=cGZIqt`9$|g!s`&as#L@-_tp3Cdr^Tz&1Zql&=noZ=nNxEs zbew(I#CyS^WV=f$3kUI3_$-o#0q_t%RokZU5Y^upPq%x@7m1h7!ayxGy_DtaiyK3pK{5MSHP;e``f}&!@^S6bfvVUuxnfjPS4Ba&~A=A)Wu$#y2{XoQ~yZyM@aaa-T z^yvqmEg7%P{PeDU{la0@k5c+%=KucbPnr_OuYRp0u9Ukk8a zM-c`Zi9NiC<@)9ac17Os*q${#J-gAi^2x>F&d%fUX@U?F=Vj*uDH=KNau23dVIAUH z_uXA`1aSm`2f9HB!KG~3-OafJfK=f&_0$1{lPe{J^m0F6&aMorvvakO^stVJ z#B~98vA1#G3l+75iB{jC*9UAamqm2s_f!n8qvNSNx7;9YWpK_MwInN!n-u5Yb(BvY zuIQic9mj3v5FCxN%pHR@P@2!3Ug&#qwAnP`l2P5wfzYdx;c&Ge*zn{tW@gyh`eq=N zp~$67oAmg2d!gc_SOc-V;(|qknftNc&WI-6*T-+${^|Y`GY&EZ!|T8fX`X<9q2hZ1 zXVls^!Eu(QGCh@3un=ZbQ()b}m32gDg}7w?{>ljOtz67d&R=&&EFcD5FuDlYtp>gP z^JlgFAobUcUW@F*^s!HT8P*%DP)WP_e9gJ#y}aNZ|LsM>(; zs@#|WdWnaNOF1Glb|FI|UAD`~t^pl=@5RY2~Z}&w5Kh5F1E4t;aq(r#7Hc_)* zF8%_s-pAdboThKXas2MtxHoPu@`ifErR+JZDl3)UJf#SUkdNZ2SHw(_8|0!ByhIT~ z6~87Xh8{IPEm{+&42Co`2p92J=udw0JZi*`aGXE=kw@KdcUV8Ncfp#mRPiacA}u!M zv>H@61QYu*McHku4#Fb58uU!5-#0_Y)x@Gm=NzwG>6t1FuMX?X3h{z`BO?a*oy=3W zP~wVGT{_gi8M!c5&#=#9Z*k4TOsZoshU888hF%Iu6@;IT&Wcaym`)d>=Nd3E^O ziaq>=zWq+(yf|fnEB{XIIZ1S=bt6E6o-a?pVNEFOMtS4wBelmU}{rukC-1=+%M|t zy5tFclG@v^hk(w6LZaY;0o&~)8RBS)5n?5XZ)l|rt^L>GsXI z0?dYj+NSU)nxA4q60m@`S!dRQ4EM;t(DSM7KjY$e^6y!fhbD8br^YPYuWVi(KvjhP z-C8a@S`qJ=DBtl*XUsij5J9@xt+kQ9v!+cRT)Eo0UKq}luU#Lv=f2AD_a_@#c@fx( zP+WCkABbql?q+wSvm%jJy55ei0)ix@g-e*^Z(6o`KQ+QrC(~$bIdYii2j6g`b;B<43G;rQVb`dh7~OOKOg=H{$6Hx6IDZyAcz)$?X+;-7Do z*tzQWoKy6^nFk)0?QLY)XVI;x)} zJVV|dQoCroQn#m#uR^t3V&&{SG`AZRR3W;^rJILg;aKta2Y8Hm?aBfICJmg`p7>k} z44j|RZz9+V3X74T`}c{MUwUImg?6aSOblE@#}-w}qCnaF^9V)s_KWUI6V92H z6-w*{+m&m3Y+9woy@sO|N-5n`eAZeTjM34O>V`v>U%BDBDl&3XxoT}je=_&ahB4h{ zOcP>@m#Wbb($FBwTsEowF2H|#$Mu?YXZV7e&hEO53?3d^I+PTTEvD_?FH%htd4pF{ zkF2j;9xz@mixz3~V3amL(t+Yu*u-d{m4&QJWz5Ff>$b!!he7 z@MeR^{?*mj($c@)hai&gv)z)YDE*qS&=cL-+he*B=6JeB1S5dmcOhw7K^R|jCBJ=o zI2yV^QFIZCs;$ktz0f4_Jrv*uxHbf-`N73J6wTQk)TP;?KeO8c+Cx!mwzI{5=H61V zC`>O&{IbaS<5M_8UO(lz`gI8Iw-a*eKle<2Isbx>0-|}0p_9$dZt|(-t!Ymsft{(b zJm?Q7Y)#j|rRe=*eW2Wpy#M`9VjGn&bH8GExok%Hde*WmRWy2?>+U^w-`(9({MB+G z3)vYVAKD3%W}S#wAe;*NrwT#kvbiwoWDk;F?&WJAYW=BK60GGjqas)5?QOyFTRdW| zdYv78syl8gr@2}1&B{Vl304FmW6;Rg2${}yNHJ9_|2(7lYihB?KZg#dQS7216zib` zXOKr|7Q;f^Iy?T_nAp}z3!dku#MM~f;@FgU0oF)bWU`9Q^0p*Imluf*33P;FLW^5qfw zMikkK6p7R)X|5QYp1ctnMShyPspeb?@3HRxjbU=QvNp)Yes{6}Q%+WpI}kB%jX?8m zghD_)QsT2Vc-7Lcqs?D7Ly}iqNl77oZ)$k5nloLNh2>ZFl>=1O9L8SH$>;-4LxU34 z1MkU!XL#Nj{JWG8zt3Z-GFcEqD;HiI3!bm7t#R&E=~Lr);665++bTJZZ+GQxS?dT)ki5#8Nobsb()G(Bi|VF7opQgb$BNAoH_ zJ}%Q=w*3d9w1`FphxkQ{|CTf3^M#kUGMG*lJzqV8RIgtLo}JY2vu$6j`mQiF{?JEa zHbX2zMa%QeBn@zLcUsPZXd~u1N+NKOLx{g=02hvFc{&HuHyl?hNPvSd*`y>=O1Ecqy?6;HI zmYjVIp=mdf-5|D6jm?Lo?VCm~(Kf$4Wv`o!LIQr}1Bcj`RJ(J`8ynBLc0 zqD514`%v1&bd7zDc~&-XLhZ%XA+6nVFpY}{wYs!*O95G3A-{ib2puu0a|Y4nu|Haf zNuz4i?uY)?#0v;Sq!gIBxPL*lE3)fyD7~R1)~c%&7LrY+#mJ~V;Ar>j&-eD;jeeCn zkIFN9Q#|r?6Cm)1*4hRfnN{;k6`&}4J9@UF}Hh#bglo3a7d7+K{ zF)nuL5x(hT3iDaV1nYC@vK+T&6uIPJ%`vT=&q;VG>4eDYaH&AKVi6xDS#dFp3q1R?VKN0#KEW~hhW*O z4FA>qp+LfyZ@yHcuD{dA@MPrsI|3^bx#cQLJ!&27CeSgVX18f>8`Y!n)-)7 z9?s$0U$AMfKeoL%A*}`VB+j>Q#nn$xsM>1PTt{M%^_)he^_+!FM*YL3-6*n4W2LW- z=&7W)>7H$YYvzLKM&rEo8yvD9NE9!aG{3jB=j4kWEQlE*@D>#X%;#(fG{WJ^H!FB~ z`yTSbIaIy;0>iS&WOwhztWiY2ANS~euEIb>R3a{rT}JjhE%vSr?z4F#Di?*WNRLGS zD_ITxICSa~X(TiWbV5I7wKek!mqld?1Pf{L;7AN4+#gN0!SV=pEW9>F!P>=Lmj{*8 zO^tYe{^&o$)}uaFvue=~cY87!DPm%6G9R|t?@wJ=geQu9b3+x*WY5{zM$aBjUEslX z9|%dNXNEfZh|SjfcE_d|vJXg`X5sB={%xQUw9=k+o3777+xz}4z1Ed4hQ$BO(Y51h z$|OBd6{4~B_3VVetrm*rsS@f;Z+%fi!ud6|wvS>{HfW71Oi6yA(;R|*JZ=12TUgXs zHnSf;ovn$!y+FM)dw9WKt|oFBBT$LF5LS6&H`#MB#)*(b)cx;^5F%o~xp>W~^9S>z zM^aHMaqoqLyizy~wg=0nT>#K3kzIsj<(~8@2>Z!gZxXkdGuvD}*4_$ug3Xv{>lG`i z?f2uyr1w!+Df!(L$HUz+9C~8witg=IFWoP##=46=d7TH(eJDtiEPf`AJ3WMUbZxpT@!m~ZEM z;unukEgsuykQP>T~owx~fV!b^JNW%yzAE|Uy=)0eW9*8`B z<^x%Ds#+>OM4w#V-!9m9lWH{zV)s|wBgZz6b6lzQV{%E}D->jp1oTO+u&sV#t0QU; zg|4!+Sp@^+?$M$(VMxS^5 zY8Z}VPr4Uu7akHHXO{72Z(UWkGZ6PRR=jTN&rTlOuKoZxdLYfyvHq&`=HK+@>gqTW zDlWP9EFe%cEcYspNKY<|p9FJ#;SdWjvHtly^!IaRH#A&)Yp%NeJw^zkdF-}*^yXkn zXf!cjmB+kIb-OutHX#3it<$7?>@rkueQsS5?~D~&Jx?^qrlp44T>UtWiqO;8kO@T% zzUqlT&ftUx*)Cdai}>r`=KzJOzbPE!(X?$ktns9_`&E58tj=#oN8g9G6ekG@W%p^| zYiQ_LqL|C^6(?KmF3dVlc)UQ0cuz(D<{JJRlhg4Py49Iu#_*M9)`$e0EsglB)d~f@ zPU8(<9dcF;au$0_2uohqBbOtwg;8fHe=xc|@)R|6Ds#tTLWw^*tp=yXyx~~#WeD^{ z=6yn$WZS~~!h+8Q-8hxh^7VSOXqKtKThcHfGm>BelkqC!XH8G07Ahuy@cQ$AU6rFUC>*&%v? zb1QaDF*`e#{)IaH$EdjfTg;%h!%zjamH_GzDMS&3EK`DQbhaRB^3F2DJq;0`yW*jn z`I9wl4AKQbr{qDGq(QXn+Xw?%8Y&C)N}cMDOXoXf^$es7sSAeUk4sN6x88T`+iS54 zA&7u6;tR->M!t`y;k z&S~UOfAsS;!Fey;aYXp%i6JIlyobk2zVo}eCA(X(r`Gs6n?Qxq?vqa$GS{T8Efof0 zqX5;wNUJ7d{(yz->+8!;(gH@X)umzF^_OJvnL<5kOnf0uuRuz67(TCS6dS=|+|ez* zxBC~;)X|WK9VUM&2@)sFa7JmG{5XD1znI3xrpy@tc8PzK?L ze+1V6Q()Cas&Dl>WowpRZ@h}A+PLJGK9Hw{3qhOsxY&SH^nnX$XJ_@TRDT~c0jCM# z>gwZj6j4z#2~qrnp{L6FMF8RzS;N6N{{2Jz#b=&L7N*WUzO)uV&=o8B$ePB(qn&g@ zrN`eUqo5cu(nBE9Ec(n0+}sgKV&tG$hJo-960**nM8K)w+wqgQt;d_2m`xgvDXgjlf{qbgvQ`Y)No@ax{p!dt{0Lu)$< zt4!qET|^aS!>&;B?}q2*_F;`_}& z!ly?8%xGAQ%__l^ckYk3C+Rc89Ip}>^kT{=v%DvuMgA2+)cbl=RJ;l}{Gpdl2+&A( zX2sOFwILzrnw?zbB0VAb^O}GE5MI2XU)kC55x~QARzkBJ!}>IQd<0c$h|0}OJLB${wn6#oF_w;K!>iw(sgHj&7 z?0cPQWtxt6Z8@<`2jyDmkb!h>B;R|=uLFv2-e=^$&1zk4CHncRmQ~`d^g{Qh9t*%F%shk7>e6!|=2irsw`A zNoS|A-Q9s41oCj}zIrjW#^LGGxH>_`P zF|gPm@A#6$;5uY_SU0UqA}b0Z4mKx#qb7VPR8W)*&cG8@4xbHy1a16iG5VCP$sCtN zvGK;N(3pC282_@+F0j=<4<9A=sv|r0*7%7HpVGYrUaNfF+r&f-kl~Zo?v`JAS?f~r zas1<5UdToq*-X=O55=6%DbNq8WNw$i)-k{G^M|BMxz{S56GV3UM26FKoVxyf0M(B`hqW$p#;KOk%{^d?Y|PM7M0e#ZeGld`kJHqk+1By z$D0#_(Bpna1#nt%n-a`=mkEKyAI*0*A0x9r4C3Pbz$DDKu(TmiDP3RL3e7_#Ge4QW zo}WJx+HxmVkZx3TC`VZG75m%SL=3bBp|Wc>*V)EP$sjR*t{%6%0b4zY1R_B309P{^1j~K@PNm}_Mzm10xVT=i5R{wj+t5B@; z-9y#F)^@3opcj>M58@D`@Es6Tx1A8~A3ZB80yh7ChIz(DwmE()@`x9HYafnfD;&Q7 z^n;V*W~SA_EbrWp(=+?iPJERrGt>l)QrVWjpKa#O=u*RGqu<%c{G&lhpyi1ktD9xo z`l{&vJNE^Jz(l~h8jA3QC}ha`rMai)X>aZ?OQ5eh{aJQUTR+&0$0i!V*32yDRzrt{ ztuyqy=KeHuXqz{F%s?t|z8_`x+AS|TCo3W%pty-_^9vmaoPM=s7!X5N#B+&_qh(&PI-e^iw0Di!?s-9+zAXg1b84Z=$j)K>vHGi=Ee^(97y6AnzJd^f-$LV;KWBYd^DJwfa8a5pR&P@ zR0OmeJVRIaZqEps$J7|m^#SJ6ZZh|JHPT~iWC&Q8vjFDVwhA=@^cYK$@It%l)?>@M zbb7i%RG-Tn1K^H9zlsJ-i4j6$%y{AW<{@9dyErR>-j7f?J1&8@QH8I*gT-=P%$EY% zn)mO$I6fyB#HL5_TYTlyD6uNY{LDTbpJM5!_^Bi4<*MZ|pmOEqr_q#@j0(>;J-vVa zye=WHRsTixYzCs8?J{H)6g{z|lrb zE$dcqMV;7h_w=CB(~DX1zR1A9-?kZ-RaN-x9do)HDEqU4?+!y!%2Qh~PG+tg1e||g zCIx_6mG7IMBIEW-zIYWqE=z!P17c1n{ut4km9xHyoMm*h_@BXz-CvpQsx2qH9lB8) z`;D0S(}e0-xYd(qf7p1k68b7hY{{G9U@_Z3OsV1YjjFpfh~Evul+rYG^-Z(vKKC|i z8rm4ddlT8Lozs6r34|su?2w&{M|5l?M)yi{cB_}-u3F&2JRjYAgcpXr^Ox%J5ld?k zfJ7m#7sKJ8l68)g|8I2&g5k!S6}F#U%}K(-kiyEh^)ll*+~{b=-BtYz#7we_&WY^J z**~SHV0;UU+Bld9}?N!X~Lgn4Kw9RZ#^!!|0szBmseUE33w9)mo`O295qReeACQcT5zqN zO>7$-@q6Gh%k=2S`&3y4W-t)I0srw@=?;$mgj{|B0lD2aweSQy$k+W4(RMp^@dp?;$~aOHRIzXnXDkPWNuA=Eqm~CBpMwT*r%^dUI^q z>A5EnQpy;1Xk6{XQ|g-VIdy`#o|of7p?u}#7G=hAq&78_f5+~|NP9L~{(~#DcrQey z*dWV%%%1%q;RwnrNSk8e%*?80Y+oPq@o^j_dz|g-gHGQ*oG8$IRabu~InfpEw}4g( z11CLak&s|0=mG`sNzAlq|18PmvTJ_h%^lp^?~q7*l7AMstFjgC5Vw z4g2vx-;>d{Z3mL!y1d~eb7nMtt>Z7XzSOtWV-Kr25Y|EGud3%a&x};s%KY`e6`;BhXMEKeT>Ysec z|2K6KTF$83^J&yo<(QAv7XGpS1+cti4hTUeNE49 zpUw7O^}%i{Z6z#XH$`R+gw7=X(TCHi&ttHL6)#(v>AJ&;n2j>fgC!9HDHYC>faVZ* z< z*$rxPvO=}DmtP*eQGV{mz#}>$8d5)x*rQfn;=f>!%j&ng-w2(mfqA-}hpYm)dY-eB2xWN}H>B zZBo7b<#0MfMtbo!9b2GDRzW|RdNts>06*^-TUM8CAN(%_wdMXs+$hV=w-uH`gmimK z={_~BV@lH>C}lfdB_f&rBqk!6t}H}r4~?9P;CJZo)6{1G6uO-$m1xtIQr*|KIUWDe zoJJ0hzk9PdQX%Gl-0Xi=@OJVorG`8VnD-2&<;VmE®w_`d`gV3yjY{|b6NDG+(F z+Dfp*;kmaQ( zgpwxhnx_R<$?z+(zcBOG)xj(O-onKv&u}*Y!5QxL?cP`t?_fsj3Ui*C1C%hkGmf%^ z$sYlM5zvGrsp|LslzMZq9neG{PhO9SWE6y`=nDqj z1!%~VaeKI+f{24Yh5YfiTrykv1_s2|_N4heH8s^wYtsen8*a~)!^|IO3%vpGm`S1{nVrYa5Y=)!`dfCh0Rn_j zm(8`DmU7cSLw9JQWpjCopTxDauI}8wxVyF3n_>Ml8_BFdMt#r0e~v37)8hNY#B3_$ zfiq(6_mhS~fUxGc4Uesct@)l)-)3G`xg!LX*ly=n;_61Ce%o{7)XTJ^xpdD%0pY88 zN1%RdaOcWZOpDk`_r^Qh929y|N=iX#IE}EoixKkU;>s85%vWuxvKDu*Wq)CRHfT+r zGsd%^_-41J$(cGl94Iq+59(F4XZ=7A0hE}QjKol{eFad^uSSB(p%@Qe|YfeXzUdkFO8W_f}7`qNU|fp^x<*l}Vf9 z+x02ZF!KF&Fc*A>P3K}`N6!dbQY%|?u*bB|Ug&g&f1a-@{yN-FhZW!F`(0)kyOOSB z^qwFm@QUH4{V{Onv#wIpE&b^DdN^PK5W*Kt=Ch=>ysY-QhX2llv}W;fB?rB-yu0EP z!NZ`?HO(u*do2H}?Vn1ryc+5MDIF%=Eqm|wt=`ej?-WTXO#&|2>5S}b*t}wRpL@)j z(>GHG35bU|Ug1ztpIgzuFOQy>l zZ<11~->-5khf1P!O3D!^VSpbBTM(z(Eg3Tut#Kydl|mLJ6|7d}8?C3syj)qg74JK1 zqvgZ=-$6!^ufNp&tRL@uyoS4;YObq7cMxFrU zy=`(ee)9{8O^Y-aD0ZEByyvqX2J_rCP`)Xl7=tPHpceiW#~_Mi2NgY5RGB@$`p=xo z`J@hit(U+6ol>0*-51L12quiX^RW>$^2N>1gd`q?-giNn5G1yO6h63@FIncUZ(wYj z7@}UW8L%>c(y1vk?KRjX-rWT%GF%^oy4kmEFwIY_1A6?<$ONJ!0QNE5Rij{6){+33 zr$QDC2C|Hdoa=`~Pa*)daLWfu1nRPl>NGdOUM;chr({kr0@elnxsL`&wEuEHk*SVl zmI8e>KffhjfzQpagDx~gMc+FXMm{U?)7eU-&m^o){;gTn7ESH5|9%xqNjVOSGU+*JN?!^@FQXL%yo@TU$)hH`Q zs~s^1%AqYXb{luqdc%Pp&49gR9VTAk=PqFSe)*uNT8qN@>`>y z!!$xH_uUC11dA9x~48ZFS z`0DB)!=iXv2~`1*Gp=>N3>n~XA=J4u7)Bd1ePBJn+b-COB zOAF9)ePUf*n*X_O@THk|H`sJ*F7-P*Ee}^Hnt63_l|*j$_C{nwCu@>%^eniSe+YP? zVNv_LWS0!c!9|17zndPaV9~`=(IH4^8iIv7xw*)=cmhh?(Uu*gdWqHR$=mxmU+WEDh<=CA(S=MtUcBI}$q(dspoKg__2F0wzUgL@8?t=7 zV&8x~8uHxV_^-y)iwhKvpify|Ny+w%Wby~mv%DL~#P&*fr2@aa3t5j9>zWKh0(w*M z0cb3<0bS0_{V)9N*Mb%h^RGM~E^=$xfhrUOd#v&yi;Rt5%WElG?5RlVeS(`g5V;s# z9SR=S!_*XYpg@|MN?bo!52-0bx|3fI!KnUDpV-n233?7ayH|(7E6Wmz2iIt$Q`U0` z4Hw^mV?#{$ZL++RN~0F4|17yu^r7t=Vz$d<%~42wBVW^XHWYB%5b*yd7QK&zPet9%Octy%~{j4aaLGWQ&Ab33uzBsp*D@t z;ff|UalgK+w`yM=(cIX8;W9&7n}e{MgeeOocrEV#+^YpCrV8YQVoCY_GEp`1ki--x){S~laCA$%ViX;?S7!J_$ zZDQ9+65(mndK-T12*LRn(zb8GZIUZK4(05V#b)J47ohds?SNMv&TO6y_p>{i@dgBxvwK}DGV3NqJ_`|hzicY*f4-toWyBP=#DhG`^_1(( zqJOUK(_*6yrn4~jA_53Gx4#NZ+#tFbL^T&;YTEW-)E>lh*XZ28fkq_<&+Uc+rxKJ| zau}ud?OPj=B1q9AZJHsfWgl8y?qf8Z$O@Ycqe+1J#kSEInQy^~V03g&S=n%R_t3dE z?B*=3+VQZ7*c|{W{X1i}#`Omz8CfPMe>Y#vg5&nY>nl zTYMj>zosAhn{X0B{%-kVyaGuHB5i zmo!D14NAFtI2+ zxFf<(WH5s2{ny15IOxE`BS8(j5di{x$m#u1@>(O;QR7vxV^C-{?DsU+Th&s15f!xr zhy*{NQ&_CR|dJ2w--ev$C&PANTG!2#n;bM z%myW%Fm)x-gDEk?A)YQVh`NJrOoNE!IBYwj1Me7*-lflkHB1B>e=d? zJOY?+_uk87q6Aq-RU;(ZOe5%VgwPVj!ik3junQg=P5YgMUcM1@ z-6dnUgT%b*f@q&jto)@R?|eX9&FGYg{sCKQ!SiM)L#}tG;==aLuQEbmf+`=M3pUX0 zgL?2NFI{Xl$*lMLqm>oMP%4AOyC|C_)O;NIx5S~M-cYvg`46v6IH55S0b}PoH5DK& zQ=xCQLn$7gC9*LxI@Ybl(l|UETuf=rVj8pXhez3!3JiuXv!@=(d@AJHTWS_VGe@UD zcU=x>8Z;Q`D^T{={n=_ZP0q2K6Klso^TM^%V2bVM1g~IoN}ON)R0-u)BwI%{i{}NF z4(;xvI+S3fZsqV-q7!j4&(^leavS`@NfcpA7-rp?{hD?utMtLZ@Gzc_Pu)iO-sM7A zBvV&sq^UwkNK_Q#*RN`>ySQw6TSLKn^R;;mj)=duhNZrI2`oq@5ibmW_bXtq%*ZZ@ zJxhiq3yP*UlVZF39TUNcixz;wNj&`x&K5G1l#~F=r(QkrO^WV3c)YK;CYuOA@V#y) zH{3WxYrb~V{lSY0u1efIBEDPNHy|ycfrpGnhO<;rRvCQI6JN)QW?(???Pa)kguc^w z_^SM4@aGLYwi0wS$1MkY`dx>2Gp=xuD%)Yu0mHD`MC=@?Dst>+{d>-}y};I>k%#OM zF;Gg=c{A#<4w}N}nm+=8jO8i>7QRLASoigxk-S3;UAu;AeAjSW4X1-_-y+J9iN!F* zibk}xhwAvWFTqFrDCflK?v_gX`a--KGx{%f>}$$hD>4uH;I_7==h?binmVe_Qq!h* z^$Nnu>cBNMBK&_9_MPEyebKu|?>)LO(Sm5vJHsfE5TZtn7NSQ&ln~t@TBIYo45B4O zH%b_Sh~7IfdWjbGzvuow-RHUG>zO(G?0xpyYrU(zhlQiAXw;@SQ+a*?|7~eV{7v}qdubVtvZOoa?Bd{ndDwe!0eQ!ch@8{y2L#knCEQ_T850aAfExCG-WWT~ z+(g!$3XPCeBS^iJcDiLhonQ^wo?s%8%1xPl2yyu~#L46lRtB7{KfM>jT7+J=0H zV7AeTEZZiMQ^fG7qIchpXV6)4)a6t-99VK#xE}9}6yH`fZ}7jFjcnkx^8zC;s&p3emI!it_H1c;GA3Lj=C|9ty1%gP zjBCXEt*&@6{3MkkMNWmG=LfL0NdCK~c6*M~#D+vf!^k8tEua)Y8=<$Kj0!)XLc-Tx z`(EdzRy?d;Vwz?}(jJP}n;26hctgWUE84~lh2W2{^p_KM_sHHq@Yu5eyM}t^HC>zr zx(SZ|OnQln!e}pr$S`c1N!WWxbVitt8-y}<; zqSr=h-B~z!={v2hZ@Ns%Ubp)c5Uxib079D)RV z$s&lUTB|S5iPBf5Qa5w3iE zIjFxzh?mbSsy4q#b$RT6d~wXPp_Qc7@uyc#(Hlk&8a$nhZfh{m0f3i4^}4Can}VY4 zefK-N^%atX1omTjSTnZLhnQqd0)zxAcw9;Lyh(24(eU6oTP!!N>ii&IZL8rsi>n58 zyXhh0_Y$vNV+lBubEKwD=ulePn!fS2kb?Hmp+j7a*08?3yjr_&A|DHM{8#o;nKMPe zV3gmJsme9GeaUH|$#)_6kAa$pyfxT8(wAx0A%EZQiVmoG#!yFm6R>FY+%P}RR3Ivz zXXZY3Oev>EH+&sxm; z0wE+?jpdZrX;(bvI-{5`_bG4A#%lPVtbVr450TM`Zocec9i!y@5|sPBK8Kqx-|#+w z|Ew@1%K8e20x#!{wGb6n&|Yi(Dl?O-)TTbp%qD=SIuAW((xu@~V<(psfeM=!G{mp0 ziDY?>T&Y0NBW-zOcJ~MGE}kT;zn5^*EgtCus`9wKy#*{~x3O-ET;n4pZJ#R5(tEEM z1MW2i<5d1w)zm3mwX@%!$21m{j9 zLtr*bZ6{o4AkWMot2Z3M4L2~L9VxYrk7c<2{r>sVuU{+y8!V+gA0k>ovTf^=vbSyB z5LP$$F~YbTLR> z2JB1S>^JQR54UHNdV20`%rvqG9c{HAMA~{6N@)q_RvOwjH{TF2^qKXujh zoYGEn7ii1`KCM$`(^&p=^2pDQRi(U-u-=4kx|L8v}joqoNh) zL0(k#k|WqAkW5}=YPR+9&nu){&qMj3q4Se#4&6-Y2ZvgK7%W#pq{Kt$4q_Tm5%^jr zCML3|JeRYwvg)yBRO4=Grec5K=2#`;5JH@Mve&(%>_d2nhet_^7?yIt$%+Zc$otyiZk_-)*WoonH$6EB z2-`3y6Fw`R661ix@XjDt<1efi2MJwVGWvL5@fTQSTfSI7~7u`w~-#dQ%Qt5Hd<4~PjH=i9KQCC5XJf+LHr6qyjM;06mHjV6= zV$AxrelTi_Io(EkeP01VHU_{0_M`)JF`d09k9lLQVu2An+hfP0feJF%~7!Fw*k!a&gP6 zfF}<|iXRsj*TcjCH4hFl`1$#5URX6kyB+KYc-%@HoHtCtzWBm{Ua@a!Y0+7QdIyBw zkS}&5XgqydIlcy1YQjn^s}~m9;|&Up!Qi!p;St#&#nXQME;pY9{fEhF9=8>JV$vK@ zqyu;f!*WW;FfC3+V)T0!IpD4IY)<+*z(Dv=hL7)0DJNYO{&$cxC@!X;rLu&n=iM_V z_&wD`wZHLbONhQ-**>0tu8OsSXkqEr($Q)JEA;C6o#q5k@~G+awYFFrafG9HnMeou ztc5>4Ew`a7czAW9FIyrW2hXd6Dd+>TIpjpICbSiF)VjTNOOBA}+WKPBW6$3(+^@Ke zpU40=1Cb<0r(Vw{r+x@F4*@o>)14zcd@g8-^vvD?2&DqqFTh&#?a6yNx+d+!EICo? z!jzQGlVbd(C?dKhoA+7>L+4Hw?8kbBAPK*20L$6SE|gC7^=J zq3*U@KpbYiGBPZ>|T|wp#rD>obwtk6v(N$q76)(%3n5U)9eFa_NmxRV{5^u zuWyZ7ROL+kXUGLBM4SAYaQ))E*NR7iv0ey?>aO5YDnJr|L*r zDrOEHC<~XTesyIGVUr~OM?x*d$_A+c#J^9Y`a|B!Yw5-1`T27)#8oCsAcx&wX(%JN zX;ib8_8*;#zPz3piTU}4ze+97Yb`a+IWho*48ZSEZ5t{K)9u0SX`yl>rcw@ z4Z)`nT+P>zuJl(1MJ88BsE}NZ2pW;&hwCe~w#kJ+2U6!uWBoW}Xl;&MGAaJ?cP5_6 z4nzx+C&pNWK@A^0upa~my=lKqO}Te#SH%BJNGAqmiAGs7B8EJMh)BW0aC#jaX2fU| zuy(}t;yz8s_|p0Lb#9oXn4^vay=Y>{;NW-CDqXle-lGeSv5$6r#2bxkzl>j12+j&aMaf?fBHny;`_#^Z3^0p zOBZz1J82OYQBYhn5r94Oi{3;TVt3!6o9$W&BSuY~oELwc96-%Q1hvI(#h~%D4VUh-X@d;?mq@>W+5+fjwnn?ecxFgklNg$^ z_S=(hN9(|32lixoRo=mEx0rcogBM!*xK`mN9e7PJfJXN%YG}_#OCow&;AJoQWtppI zgPEZRt7~x|2k!AkM!{1v%gjp82KWGKqex=BF<14FN@#Gvd$|H*5O~oLQX9{la(Xb@ zIaAA^LPDc%|ETct-*WfD-wjNn=IXz{H5K01B0sWK+|l%rh|^D3J0am}J|8xluktJD z-;TIx0)mdDRGRbiZNz9*O-$mo&CTkYJF}Nsea@e1S5^$VaYRnTU%6zd!QRHMD1Y+D zuYM~M@jVCs&FX5++#*5Ja(6%INoP7dJUZj>aN-L|lOl6MpA$pLosQm=WMTHrkPaic zab7_V&~GNJtf4U2lSvtHiE^quyDNwZgIOGLD_bpy2SEicNn+q#y-rso0b2~gJT@)H z64;`amb)Jxo%rf_xIb9grumS|6SufvU~NnY8bt%IJd<$`Jsrr`QxS7mH=P!H3J(od zgE+WCSnj#GUBPtZz!ccj^{57B0x5StFNW^Y*}L|=OkP(H#3v)&XZ!boeLuF{7qc2Zsi zXC#Lo=UMEWA3f&b#)k~ve27gGYmCg}yZt~lL@6Ek*$z6S?&oI~m3#9UFV1gMQjOTy zumtQ2d}(ah|LJl=C>bakPxKKd1OpbNUrd5tLR&lH=!;t|w)O$u3Hr3O1~SpRMJC$! zDItg9Is}36oUvRN80dX;+&dz%5GhsOjbvd1en&^Lb^QZLN2E;!P;`ia zSA4WmY`kSwWT(x|Zdd6cuJ;zu78M&l-{XDt z4p1rPYA?S2CMgOE`S)p5)Rr?8duJqp>Dl$iZcQhs6J(uIOs;1<`_bq6v)eG_ps4>; z;Z8b=f`H1jq_Vs^W^~ePl$o9oVEvbNL5Ij}JcyTxiKWuFc` zq@d8r)Vr;c68Dtu+I;W928W1w&8mRy1~etpQ*%$S2Du>20gkaOfc7{h z<(Mtd+Dd0A8K{kT(6ii)Jv~Be{8<{p{#{$JUji69EuMMtWeka^URrcL85!|*ehDfR z_@aTJ?F1ZPn$z9IwCANiTJb^PYau}I{)hg+K(BH9SgRRqaD9L7!NbTJ^obDf*AA** zK==gMC|#t!8@@Nr7N6kmUukDk$x;>f|KE__{5c_3RFJYRlJ_9)e{go!$&)V$evbwA8w- zmG<5Ew}f9T6(GVowBxNA)lC>nRZoS1NHz!j>3O(q8L&dV#m}pj z@tzb|DFO6Tvi9BG-!qLj-qKZ0@RwC@j1OYT-%weyQ2HherA$o7SeikAM@81Mz>d@~ zt)@2s=qp!Of>#Jp%;t;B`f)d4o@`!BA#T%DapDf%DeQ?)_1E^^E$O zrPu01S(mDss;7eK&OI(?x2*yBxO#YaySHuMTJrHPwV{f+ zmAYfOiM;@FA|U^a8u%slwZMQ_QIf&CK1e2P+u7l@gYKTI(&WDeKl1?L1j^fO;M-)X z;GiK99Hn~GZdgxEmKf21$o@^iRp8<}LiWFw#ZBOOxqZ1XvbP*+8V^j!OT4N&?}AgZpye1q&=$Khe-I|zw;0~CUjzpDwdFz&^RwIs~~Tw ziD@!t1bD{?1o0RNA+mQJgf_5DN)m>80kty{T{00Q@fgkPcjGVsHn37r0dWC-EOJF; zTr9VQkyFLJk_b_3I@*_)tg|n3A))mLYmR;x0n2J`_8COKYj`e?Q-R=svTs~ukF*1; z>lo^LdEuQQsjY;Td7<)C%+~Wz0iFxr`|7kH77$e}yP=gpuL|O+SCT~19yRsNR8gq= zR{7fuhK09H7n`+Hl~Hz$eI+uve;BM0j(C!_gQk90vM`igJ}NE z2FL6tu*-L3U&UEM>Fin6OEL;YMJSYCj7Ak$C!p&oMJ4h~iVb~Eq(aCj5hpQRaoa(q zR)wH{ z^n3uin$*Mu1lEZ-MwpGTi>Q$7STl6{Fz;ksr-nXgL@e1QN>a?~JcU;l8x){uaN|=aZsOKA!Xr=&M_~-3G|(=@>c$fuUlB0Nx#_L)dBV2K(LV8W_blN@@fVJ_p&b)x3flVFDI~)w`FB1 z$7>nP{`7mA$@uC<&uGJ-w&lji+FnSF(r3LgSdqoD=#%w(LUi-1&ZtpGAn ztD`_Kup2SDYuiG9eOVs;g833>)skAV!tA)$k z6K()EIg{BY)Tzt{f<{#@?^n;iMuZpj+}RDL$iK&7Rp|bk$Q~K|AgiY4RYiu<8;zK_ zqu1=LVlbmZ@uk$e-a*p}IP*3@!JGvw8ow_KInV)G!m$uMjq}tCN@{^Z7NrGdbn2S4L7i+}z$vohe#9SBJ;J zrw3ec-w4=ttFk~1yE-~K*&VD6Bi+mYqU3k3Ta$eAS=N1G7KXgTYg7mpzjdl|@5T+C zk}nq7T7P&_x+j&6b%aF{JiiQ&J2^RB6BO*48g^lFHo`_ are used to map isotope to hash values with which all possible isotopes can be described. + A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. + + :ref:`NXlens_em`: + A base class to detail an electro-magnetic lens. In practice, an electron microscope has many such lenses. It is possible to specify as many lenses as necessary to represent eventually each single lens of the microscope and thus describe how the lenses are affecting the electron beam. This can offer opportunities for developers of software tools which strive to model the instrument e.g. to create digital twins of the instrument. We understand there is still a way to go with this to arrive there though. Consequently, we suggest to focus first on which details should be collected for a lens as a component so that developers of application definitions can take immediate advantage of this work. + + :ref:`NXfabrication`: + A base class to bundle manufacturer/technology-partner-specific details about + a component or device of an instrument. :ref:`NXoptical_system_em`: A base class to store for now qualitative and quantitative values of frequent interest @@ -130,35 +98,34 @@ The following base classes are proposed to support modularizing the storage of p Examples are the semiconvergence angle or the depth of field and depth of focus, the magnification, or the camera length. :ref:`NXpeak`: - A base class to describe peaks mathematically. + A base class to describe peaks mathematically so that it can be used to detail how peaks in mass-to-charge-state ratio histograms (aka mass spectra) are defined and labelled as iontypes. + + :ref:`NXpump`: + A base class to describe details about a pump in an instrument. - :ref:`NXcircuit`: - A base class to describe a logical unit of at least one integrated circuit. + :ref:`NXscanbox_em`: + A base class to represent the component of an electron microscope which realizes a controlled deflection (and eventually shift, blanking, and/or descanning) of the electron beam to illuminate the specimen in a controlled manner. This can be used to document the scan pattern. + :ref:`NXspectrum_set`: + Base class and specializations comparable to NXimage_set but for storing spectra. Specialized base classes should use controlled vocabulary items as prefixes such as **eels** electron energy loss spectroscopy, **xray** X-ray spectroscopy (EDS/STEM, EDX, SEM/EDX, SEM/EDS), **auger** Auger spectroscopy, or **cathodolum** for cathodoluminescence spectra. + + :ref:`NXstage_lab`: + As it was mentioned for atom probe microscopy, this is a base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities which modern stages of electron microscopes frequently offer. -.. _EmAnalysisClasses: +Method-specific concepts and their usage in application definitions +################################################################### -We provide specific base classes which granularize frequently collected or analyzed quantities in specific application fields of electron microscopy to deal -with the situation that there are cases were logical connections between generated data artifacts mainly exist for the fact that the data artifacts were -collected during a workflow of electron microscopy research (e.g. taking measurements and then performing method-specific analyses generating new data and conclusions). -We see a value in granularizing out these pieces of information into own classes. In fact, one limitation of application definitions in NeXus, exactly as it applies for serialization -of information also more generally, is currently that they define a set of constraints on their graph of controlled concepts and terms. +It became clear during the design of the electron-microscopy-specific additions to NeXus that there are sets of pieces of information (data and metadata) which are relevant for a given experiment but have usually only few connections to the detailed description of the workflow of processing these data into knowledge, motivating the granularization of these pieces of information in their own application definition. In fact, one limitation of application definitions in NeXus is that they define a set of constraints on their graph of controlled concepts and terms. If we take for example diffraction experiments with an electron microscope it is usually the case that (diffraction) patterns are collected in the session at the microscope but all scientifically relevant conclusions are drawn later, i.e. through post-processing these data. These numerical and algorithmic steps define computational workflows where data from the application definitions such as NXem are used as input but many additional concepts and constraints may apply without any need for changing constraints on fields or groups of NXem. If we were to modify NXem for these cases, NXem would likely combinatorially diverge as every different combination of required constraints would demand having their own but almost similar application definition. For this reason, we propose to define the following base classes: -If we take for example diffraction experiments performed with an electron microscope, it is usually the case that (diffraction) patterns are collected in the session at the microscope. -However, all scientifically relevant conclusions are typically drawn later, i.e. through post-processing the collected diffraction (raw) data. These numerical and algorithmic steps -define computational workflows were data from an instance of an application definition such as NXem are used as input but many additional concepts, constraints, and assumptions -are applied without that these demand necessarily changes in the constraints on fields or groups of NXem. If we were to modify NXem for these cases, -NXem would combinatorially diverge as every different combination of required constraints demands having an own but almost similar application definition. -For this reason, method-specific base classes are used which granularize out how specific pieces of information are processed further to eventually enable their -storage (i.e. serialization) using NeXus. +More consolidation through the use of NXsubentry classes should be considered in the future. -More consolidation through the use of NXsubentry classes should be considered in the future. For now we use an approach whereby base classes are combined to reuse vocabulary and a hierarchical organization of pieces of information with specific constraints which are relevant only for specific usage of such data by specific tools used by an eventually smaller circle of users. + :ref:`NXem_ebsd`: + Application definition for collecting and indexing Kikuchi pattern into orientation maps for the two-dimensional, three- and four-dimensional case. - :ref:`NXem_method`, :ref:`NXem_ebsd`, :ref:`NXem_eds`, :ref:`NXem_eels`, :ref:`NXem_img`, :ref:`NXem_correlation`: - Base classes with method-specific details especially when it comes to reporting post-processed data within electron microscopy. +Several new base classes are used by this application definition. - :ref:`NXcrystal_structure`: - A base class to store crystalline phase/structure used for a simulation of diffraction pattern and comparison of these pattern against patterns to support indexing. + :ref:`NXem_ebsd_conventions`: + A collection of reference frames and rotation conventions necessary to interpret the alignment and orientation data. - :ref:`NXroi`: - A base class to granularize information collected and relevant for the characterization of a region-of-interest. + :ref:`NXem_ebsd_crystal_structure_model`: + A description of a crystalline phase/structure used for a forward simulation using kinetic or dynamic diffraction theory to generate simulated diffraction pattern against which measured pattern can be indexed. diff --git a/manual/source/classes/contributed_definitions/icme-structure.rst b/manual/source/classes/contributed_definitions/icme-structure.rst deleted file mode 100644 index 68c6f9859..000000000 --- a/manual/source/classes/contributed_definitions/icme-structure.rst +++ /dev/null @@ -1,48 +0,0 @@ -.. _Icme-Structure: - -============================================== -Integrated Computational Materials Engineering -============================================== - -.. index:: - IcmeMsModels - -.. _IcmeMsModels: - -Application definitions for ICME models -####################################### - -It is important to embrace the large research community of materials engineers -as they are frequent users of electron microscopy and atom probe microscopy. -ICME is an abbreviation for Integrated Computational Materials Engineering, which is -a design strategy and workflow whereby physics-based modelling of microstructure -evolution is used to understand the relations between the microstructure and -its technologically relevant descriptors to understand and tailor properties of materials. - -The following application definitions are proposed to support the discussion on how -materials-engineering-specific data schemas can connect to or be mapped on -concepts which are equally modellable with NeXus: - - :ref:`NXmicrostructure`: - A base class for documenting a snapshot of a reconstructed microstructure. - - :ref:`NXmicrostructure_imm_config`, :ref:`NXmicrostructure_imm_results`: - A specific example of an application definition for documenting the - configuration and results respectively of a computer simulation with - the legacy microstructure synthesizer developed at the Institut für - Metallkunde und Metallphysik in Aachen. - - :ref:`NXmicrostructure_kanapy_results`: - A specific example of an application definition for documenting the results - of a computer simulation with the kanapy microstructure synthesizer - developed at the ICAMS in Bochum. - - :ref:`NXmicrostructure_score_config`, :ref:`NXmicrostructure_score_results`: - A specific example of an application definition for documenting the - configuration and results respectively of a computer simulation with - the static recrystallization cellular automata model SCORE. - - :ref:`NXmicrostructure_gragles_config`, :ref:`NXmicrostructure_gragles_results`: - A specific example of an application definition for documenting the - configuration and results respectively of a computer simulation with - the grain growth level-set-based model GraGLeS. diff --git a/manual/source/classes/contributed_definitions/mpes-structure.rst b/manual/source/classes/contributed_definitions/mpes-structure.rst index ab05f3a79..1d37fdba6 100644 --- a/manual/source/classes/contributed_definitions/mpes-structure.rst +++ b/manual/source/classes/contributed_definitions/mpes-structure.rst @@ -1,8 +1,8 @@ .. _Mpes-Structure: -======================================= +============================================== Photoemission & core-level spectroscopy -======================================= +============================================== .. index:: IntroductionMpes @@ -17,7 +17,7 @@ Photoemission & core-level spectroscopy Introduction ############ -Set of data storage objects to describe multidimensional photoemission (MPES) experiments including x-ray photoelectron spectroscopy (XPS), ultraviolet photoelectron spectroscopy (UPS), +Set of data storage objects to describe photoemission experiments including x-ray photoelectron spectroscopy (XPS), ultraviolet photoelectron spectroscopy (UPS), hard x-ray photoelectron spectroscopy (HAXPES), angle-resolved photoemission spectroscopy (ARPES), two-photon photoemission (2PPE) and photoemission electron microscopy (PEEM). Also includes descriptors for advanced specializations, such as spin-resolution, time resolution, near-ambient pressure conditions, dichroism etc. @@ -28,13 +28,7 @@ Application Definitions ####################### :ref:`NXmpes`: - A general application definition with minimalistic metadata requirements, apt to describe all photoemission experiments. - - :ref:`NXmpes_arpes`: - An application definition for angle-resolved photoemission spectroscopy (ARPES) experiments. - - :ref:`NXxps`: - An application definition for X-ray/ultraviolet photoelectron spectroscopy (XPS/UPS) measurements. + A general appdef with minimalistic metadata requirements, apt to describe all photemission experiments. .. _MpesBC: @@ -67,25 +61,16 @@ Three base classes to describe data processing, which can be used as subclasses :ref:`NXregistration`: A base class to describe the rigid transformations that are applied to an image. May be redundant as they can be described with :ref:`NXtransformations`. - - :ref:`NXprocess_mpes`: - A base class specializing :ref:`NXprocess`, describing events of data processing, reconstruction, or analysis for photoemission-related data. .. _MpesCommonBC: Common Base Classes ################### -There are related base classes that are common to other techniques: +There are two related base classes that are common to other techniques: :ref:`NXlens_em`: A class to describe all types of lenses. Includes electrostatic lenses for electron energy analysers. :ref:`NXdeflector` - A class to describe all kinds of deflectors, including electrostatic and magnetostatic deflectors for electron energy analysers. - - :ref:`NXresolution`: - Describes the resolution of a physical quantity, e.g. the resolution of the MPES spectrometer. - - :ref:`NXfit`, :ref:`NXpeak`, :ref:`NXfit_background`, :ref:`NXfit_function`, :ref:`NXfit_parameter`: - Base classes for describing a fit procedure, e.g. a peak fitting in energy space in XPS. \ No newline at end of file + A class to describe all kinds of deflectors, including electrostatic and magnetostatic deflectors for electron energy analysers. \ No newline at end of file diff --git a/manual/source/classes/contributed_definitions/sample-prep-structure.rst b/manual/source/classes/contributed_definitions/sample-prep-structure.rst deleted file mode 100644 index 39f8249e9..000000000 --- a/manual/source/classes/contributed_definitions/sample-prep-structure.rst +++ /dev/null @@ -1,20 +0,0 @@ -.. _Synthesis-Structure: - -================== -Sample preparation -================== - -.. index:: - SamplePreparation - -.. _SamplePreparation: - -Document steps of wet-lab sample preparation -############################################ - -Virtually all experiments require a preparation of the sample. As most techniques are surface-sensitive or probe exclusively the surface, the use of careful preparation -techniques is the key to successful experiments. Unfortunately, the quality of such processes is often difficult to reproduce. Nevertheless, documenting how samples -are prepared is relevant. This part of the proposal provides prototypes how descriptions of steps performed by human or robots in a lab could be described using NeXus. - - :ref:`NXlab_electro_chemo_mechanical_preparation`, :ref:`NXlab_sample_mounting`: - Prototype application definitions for documenting steps during sample preparation. diff --git a/manual/source/classes/contributed_definitions/sts-structure.rst b/manual/source/classes/contributed_definitions/sts-structure.rst deleted file mode 100644 index 42aef5e6e..000000000 --- a/manual/source/classes/contributed_definitions/sts-structure.rst +++ /dev/null @@ -1,47 +0,0 @@ -.. _Stm-Structure: - -=============================== -Scanning Tunneling Spectroscopy -=============================== - -.. index:: - StsAppDef - StsBC - -.. _StsAppDef: - -Application Definition -###################### - - :ref:`NXsts`: - An application definition for scanning tunneling spectroscopy experiments. - -.. _StsNewBC: - -Base Classes -############ - - :ref:`NXamplifier`: - A base class - - :ref:`NXbias_spectroscopy`: - A base class - - :ref:`NXcircuit`: - A base class - - :ref:`NXiv_bias`: - A base class - - :ref:`NXlockin`: - A base class - - :ref:`NXpid`: - A base class - - :ref:`NXpositioner_sts`: - A base class - - :ref:`NXsensor_scan`: - A base class - diff --git a/manual/source/classes/contributed_definitions/transport-structure.rst b/manual/source/classes/contributed_definitions/transport-structure.rst index be41f0f78..6aaf6844e 100644 --- a/manual/source/classes/contributed_definitions/transport-structure.rst +++ b/manual/source/classes/contributed_definitions/transport-structure.rst @@ -12,7 +12,7 @@ Transport Phenomena .. _IntroductionTransport: Introduction -############ +############## .. _TransportAppDef: @@ -20,5 +20,13 @@ Introduction Application Definitions ####################### +We realize that many experiments in condensed-matter physics and materials engineering belong to the category +of measurements of transparent phenomena. A possible example of such experiments are temperature-dependent +current-voltage (IV) curve measurements (or JV for engineers) measurements. In this case, electrical charge is transported +and the temperature-dependent current response as a function of applied voltage is recorded. + +Below is an example for such an application definition for an experiment. This application definition has exemplar parts +which show how such an experiment can be controlled with the `EPICS system `_: + :ref:`NXiv_temp`: Application definition for temperature-dependent current-voltage (IV) curve measurements.