From ce7bf1fa8e5bf6df9959db0255abb8bf7a5a00ed Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Fri, 2 Jun 2023 12:23:59 +0200 Subject: [PATCH 01/18] Temporary fix bypassing git repo bootstrapping to enable a working apm example in update-north-markus nomad FAIR --- pynxtools/dataconverter/readers/shared/shared_utils.py | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/pynxtools/dataconverter/readers/shared/shared_utils.py b/pynxtools/dataconverter/readers/shared/shared_utils.py index 59d28ba6d..9e1a8227f 100644 --- a/pynxtools/dataconverter/readers/shared/shared_utils.py +++ b/pynxtools/dataconverter/readers/shared/shared_utils.py @@ -27,10 +27,12 @@ def get_repo_last_commit() -> str: """Identify the last commit to the repository.""" - repo = git.Repo(search_parent_directories=True) - sha = str(repo.head.object.hexsha) - if sha != "": - return sha + # repo = git.Repo(search_parent_directories=True) + # sha = str(repo.head.object.hexsha) + # if sha != "": + # return sha + # currently update-north-markus branch on nomad-FAIR does not pick up + # git even though git in the base image and gitpython in pynxtools deps return "unknown git commit id or unable to parse git reverse head" From df24b2ff3d0fdf5bde5cd036ede25ca9d3a2eed2 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Fri, 2 Jun 2023 12:29:49 +0200 Subject: [PATCH 02/18] Fixed linting --- pynxtools/dataconverter/readers/shared/shared_utils.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pynxtools/dataconverter/readers/shared/shared_utils.py b/pynxtools/dataconverter/readers/shared/shared_utils.py index 9e1a8227f..629e29a0f 100644 --- a/pynxtools/dataconverter/readers/shared/shared_utils.py +++ b/pynxtools/dataconverter/readers/shared/shared_utils.py @@ -22,7 +22,7 @@ # pylint: disable=E1101, R0801 -import git +# import git def get_repo_last_commit() -> str: From 59430c70b6e7e66cf38568456b7e40f1e05457ac Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Sat, 10 Jun 2023 15:14:07 +0200 Subject: [PATCH 03/18] Updated definitions to include customizations for making the june deployment for atom probe groups like Leoben and others --- pynxtools/definitions | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pynxtools/definitions b/pynxtools/definitions index 970e55d63..e0079c9a4 160000 --- a/pynxtools/definitions +++ b/pynxtools/definitions @@ -1 +1 @@ -Subproject commit 970e55d6381a6418eac3045a2df034eaf8b8b5b3 +Subproject commit e0079c9a4a3d40d041c27f29415e5250590769a9 From cf6a36bc5ee885e6e512608d57a824ec3dabab01 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Sat, 10 Jun 2023 17:54:46 +0200 Subject: [PATCH 04/18] em_nion, apm: Renaming source code files to make clearer their purpose and functionality, apm: started refactoring loading of ELN data to use em_nion concept of mapping tables instead of custom, hardcoded many section-specific functions, apm: Added support for decoupling metadata from ELN and a deployment-specific configuration file, whereby users of specific OASIS do no longer need to expose all metadata in the ELN template but can instead use the deployment-specific configuration file to inject e.g. not changing metadata like versions, or specific details about instruments directly from the configuration yaml file, thereby the amount of retyping in ELNs can be reduced, an additional potential benefit of this design is that ELNs may appear now less complex for end users which was a point raised by Lorenz Romaner from Leoben --- .../apm_deployment_specifics_to_nx_map.py | 51 + .../apm/map_concepts/apm_eln_to_nx_map.py | 83 + pynxtools/dataconverter/readers/apm/reader.py | 21 +- ...lots.py => apm_create_nx_default_plots.py} | 0 ...ase_selector.py => apm_define_io_cases.py} | 26 +- ...data.py => apm_generate_synthetic_data.py} | 2 +- .../utils/apm_load_deployment_specifics.py | 60 + ...eric_eln_io.py => apm_load_generic_eln.py} | 0 ...{apm_ranging_io.py => apm_load_ranging.py} | 0 ...ction_io.py => apm_load_reconstruction.py} | 0 .../readers/apm/utils/apm_utils.py | 26 - .../{concepts => map_concepts}/README.md | 0 .../swift_display_items_to_nx.py} | 0 .../swift_eln_to_nx_map.py} | 0 .../swift_to_nx_image_ang_space.py} | 0 .../swift_to_nx_image_real_space.py} | 0 .../swift_to_nx_spectrum_eels.py} | 0 .../dataconverter/readers/em_nion/reader.py | 4 +- .../{versioning.py => em_nion_versioning.py} | 0 ...e_selector.py => swift_define_io_cases.py} | 0 ...xes.py => swift_generate_dimscale_axes.py} | 2 +- ...ic_eln_io.py => swift_load_generic_eln.py} | 8 +- .../utils/swift_zipped_project_parser.py | 12 +- .../map_concepts/mapping_functors.py} | 0 pynxtools/definitions | 2 +- pynxtools/nyaml2nxdl/NXapm.nxdl.xml | 1696 +++++++++++++++++ pynxtools/nyaml2nxdl/NXapm.yaml | 1548 +++++++++++++++ .../nxapm.schema.archive.yaml | 334 ++-- 28 files changed, 3686 insertions(+), 189 deletions(-) create mode 100644 pynxtools/dataconverter/readers/apm/map_concepts/apm_deployment_specifics_to_nx_map.py create mode 100644 pynxtools/dataconverter/readers/apm/map_concepts/apm_eln_to_nx_map.py rename pynxtools/dataconverter/readers/apm/utils/{apm_nexus_plots.py => apm_create_nx_default_plots.py} (100%) rename pynxtools/dataconverter/readers/apm/utils/{apm_use_case_selector.py => apm_define_io_cases.py} (75%) rename pynxtools/dataconverter/readers/apm/utils/{apm_example_data.py => apm_generate_synthetic_data.py} (99%) create mode 100644 pynxtools/dataconverter/readers/apm/utils/apm_load_deployment_specifics.py rename pynxtools/dataconverter/readers/apm/utils/{apm_generic_eln_io.py => apm_load_generic_eln.py} (100%) rename pynxtools/dataconverter/readers/apm/utils/{apm_ranging_io.py => apm_load_ranging.py} (100%) rename pynxtools/dataconverter/readers/apm/utils/{apm_reconstruction_io.py => apm_load_reconstruction.py} (100%) delete mode 100644 pynxtools/dataconverter/readers/apm/utils/apm_utils.py rename pynxtools/dataconverter/readers/em_nion/{concepts => map_concepts}/README.md (100%) rename pynxtools/dataconverter/readers/em_nion/{concepts/swift_display_items_to_nx_concepts.py => map_concepts/swift_display_items_to_nx.py} (100%) rename pynxtools/dataconverter/readers/em_nion/{concepts/generic_eln_mapping.py => map_concepts/swift_eln_to_nx_map.py} (100%) rename pynxtools/dataconverter/readers/em_nion/{concepts/nx_image_ang_space.py => map_concepts/swift_to_nx_image_ang_space.py} (100%) rename pynxtools/dataconverter/readers/em_nion/{concepts/nx_image_real_space.py => map_concepts/swift_to_nx_image_real_space.py} (100%) rename pynxtools/dataconverter/readers/em_nion/{concepts/nx_spectrum_eels.py => map_concepts/swift_to_nx_spectrum_eels.py} (100%) rename pynxtools/dataconverter/readers/em_nion/utils/{versioning.py => em_nion_versioning.py} (100%) rename pynxtools/dataconverter/readers/em_nion/utils/{use_case_selector.py => swift_define_io_cases.py} (100%) rename pynxtools/dataconverter/readers/em_nion/utils/{swift_dimscale_axes.py => swift_generate_dimscale_axes.py} (96%) rename pynxtools/dataconverter/readers/em_nion/utils/{em_generic_eln_io.py => swift_load_generic_eln.py} (95%) rename pynxtools/dataconverter/readers/{em_nion/concepts/swift_handle_nx_concepts.py => shared/map_concepts/mapping_functors.py} (100%) create mode 100644 pynxtools/nyaml2nxdl/NXapm.nxdl.xml create mode 100644 pynxtools/nyaml2nxdl/NXapm.yaml diff --git a/pynxtools/dataconverter/readers/apm/map_concepts/apm_deployment_specifics_to_nx_map.py b/pynxtools/dataconverter/readers/apm/map_concepts/apm_deployment_specifics_to_nx_map.py new file mode 100644 index 000000000..0a56be5d8 --- /dev/null +++ b/pynxtools/dataconverter/readers/apm/map_concepts/apm_deployment_specifics_to_nx_map.py @@ -0,0 +1,51 @@ +# +# Copyright The NOMAD Authors. +# +# This file is part of NOMAD. See https://nomad-lab.eu for further info. +# +# Licensed under the Apache License, Version 2.0 (the "License"); +# you may not use this file except in compliance with the License. +# You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. +# +"""Dict mapping values for a specific deployed config of NOMAD OASIS + ELN + apm reader.""" + +# pylint: disable=no-member,line-too-long + +# currently by virtue of design NOMAD OASIS specific examples show how different tools and +# services can be specifically coupled and implemented so that they work together +# currently we assume that the ELN provides all those pieces of information to instantiate +# a NeXus data artifact which technology-partner-specific files or database blobs can not +# deliver. Effectively a reader uses the eln_data.yaml generic ELN output to fill in these +# missing pieces of information while typically heavy data (tensors etc) are translated +# and written from the technology-partner files +# for large application definitions this can lead to a practical inconvenience: +# the ELN that has to be exposed to the user is complex and has many fields to fill in +# just to assure that all information are included in the ELN output and thus consumable +# by the dataconverter +# taking the perspective of a specific lab where a specific version of an ELN provided by +# or running in addition to NOMAD OASIS is used many pieces of information might not change +# or administrators do not wish to expose this via the end user ELN in an effort to reduce +# the complexity for end users and make entering of repetitiv information obsolete + +# this is the scenario for which deployment_specific mapping shines +# parsing of deployment specific details in the apm reader is currently implemented +# such that it executes after reading generic ELN data (eventually available entries) +# in the template get overwritten + +from pynxtools.dataconverter.readers.apm.utils \ + import NX_APM_ADEF_NAME, NX_APM_ADEF_VERSION, NX_APM_EXEC_NAME, NX_APM_EXEC_VERSION + + +NxApmDeploymentSpecificInput \ + = {"ENTRY[entry*]/@version": f"{NX_APM_ADEF_VERSION}", + "ENTRY[entry*]/definition": f"{NX_APM_ADEF_NAME}", + "ENTRY[entry*]/PROGRAM[program1]/program": f"{NX_APM_EXEC_NAME}", + "ENTRY[entry*]/PROGRAM[program1]/program/@version": f"{NX_APM_EXEC_VERSION}"} diff --git a/pynxtools/dataconverter/readers/apm/map_concepts/apm_eln_to_nx_map.py b/pynxtools/dataconverter/readers/apm/map_concepts/apm_eln_to_nx_map.py new file mode 100644 index 000000000..45b569761 --- /dev/null +++ b/pynxtools/dataconverter/readers/apm/map_concepts/apm_eln_to_nx_map.py @@ -0,0 +1,83 @@ +# +# Copyright The NOMAD Authors. +# +# This file is part of NOMAD. See https://nomad-lab.eu for further info. +# +# Licensed under the Apache License, Version 2.0 (the "License"); +# you may not use this file except in compliance with the License. +# You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. +# +"""Dict mapping custom schema instances from eln_data.yaml file on concepts in NXapm.""" + +NxApmElnInput = {"IGNORE": {"fun": "load_from_dict_list", "terms": "em_lab/detector"}, + "IGNORE": {"fun": "load_from", "terms": "em_lab/ebeam_column/aberration_correction/applied"}, + "IGNORE": {"fun": "load_from_dict_list", "terms": "em_lab/ebeam_column/aperture_em"}, + "/ENTRY[entry*]/em_lab/EBEAM_COLUMN[ebeam_column]/electron_source/emitter_type": {"fun": "load_from", "terms": "em_lab/ebeam_column/electron_source/emitter_type"}, + "/ENTRY[entry*]/em_lab/EBEAM_COLUMN[ebeam_column]/electron_source/voltage/@units": {"fun": "load_from", "terms": "em_lab/ebeam_column/electron_source/voltage/unit"}, + "/ENTRY[entry*]/em_lab/EBEAM_COLUMN[ebeam_column]/electron_source/voltage": {"fun": "load_from", "terms": "em_lab/ebeam_column/electron_source/voltage/value"}, + "/ENTRY[entry*]/em_lab/FABRICATION[fabrication]/capabilities": {"fun": "load_from", "terms": "em_lab/fabrication/capabilities"}, + "/ENTRY[entry*]/em_lab/FABRICATION[fabrication]/identifier": {"fun": "load_from", "terms": "em_lab/fabrication/identifier"}, + "/ENTRY[entry*]/em_lab/FABRICATION[fabrication]/model": {"fun": "load_from", "terms": "em_lab/fabrication/model"}, + "/ENTRY[entry*]/em_lab/FABRICATION[fabrication]/vendor": {"fun": "load_from", "terms": "em_lab/fabrication/vendor"}, + "/ENTRY[entry*]/em_lab/instrument_name": {"fun": "load_from", "terms": "em_lab/instrument_name"}, + "/ENTRY[entry*]/em_lab/location": {"fun": "load_from", "terms": "em_lab/location"}, + "IGNORE": {"fun": "load_from", "terms": "em_lab/optical_system_em/beam_current/unit"}, + "IGNORE": {"fun": "load_from", "terms": "em_lab/optical_system_em/beam_current/value"}, + "IGNORE": {"fun": "load_from", "terms": "em_lab/optical_system_em/beam_current_description"}, + "IGNORE": {"fun": "load_from", "terms": "em_lab/optical_system_em/magnification"}, + "IGNORE": {"fun": "load_from", "terms": "em_lab/optical_system_em/semi_convergence_angle/unit"}, + "IGNORE": {"fun": "load_from", "terms": "em_lab/optical_system_em/semi_convergence_angle/value"}, + "/ENTRY[entry*]/em_lab/stage_lab/description": {"fun": "load_from", "terms": "em_lab/stage_lab/description"}, + "/ENTRY[entry*]/em_lab/stage_lab/name": {"fun": "load_from", "terms": "em_lab/stage_lab/name"}, + "/ENTRY[entry*]/@version": {"fun": "load_from", "terms": "entry/attr_version"}, + "/ENTRY[entry*]/definition": {"fun": "load_from", "terms": "entry/definition"}, + "/ENTRY[entry*]/end_time": {"fun": "load_from", "terms": "entry/end_time"}, + "/ENTRY[entry*]/experiment_description": {"fun": "load_from", "terms": "entry/experiment_description"}, + "/ENTRY[entry*]/experiment_identifier": {"fun": "load_from", "terms": "entry/experiment_identifier"}, + "/ENTRY[entry*]/PROGRAM[program*]/program": {"fun": "load_from", "terms": "entry/program"}, + "/ENTRY[entry*]/PROGRAM[program*]/program/@version": {"fun": "load_from", "terms": "entry/program__attr_version"}, + "/ENTRY[entry*]/start_time": {"fun": "load_from", "terms": "entry/start_time"}, + "IGNORE": {"fun": "load_from_list_of_dict", "terms": "user"}} + +# NeXus concept specific mapping tables which require special treatment as the current +# NOMAD OASIS custom schema implementation delivers them as a list of dictionaries instead +# of a directly flattenable list of keyword, value pairs + +NxApertureEmFromListOfDict = {"/ENTRY[entry*]/em_lab/EBEAM_COLUMN[ebeam_column]/APERTURE_EM[aperture_em*]/name": {"fun": "load_from", "terms": "name"}, + "/ENTRY[entry*]/em_lab/EBEAM_COLUMN[ebeam_column]/APERTURE_EM[aperture_em*]/value": {"fun": "load_from", "terms": "value"}} + +NxUserFromListOfDict = {"/ENTRY[entry*]/USER[user*]/name": {"fun": "load_from", "terms": "name"}, + "/ENTRY[entry*]/USER[user*]/affiliation": {"fun": "load_from", "terms": "affiliation"}, + "/ENTRY[entry*]/USER[user*]/address": {"fun": "load_from", "terms": "address"}, + "/ENTRY[entry*]/USER[user*]/email": {"fun": "load_from", "terms": "email"}, + "/ENTRY[entry*]/USER[user*]/orcid": {"fun": "load_from", "terms": "orcid"}, + "/ENTRY[entry*]/USER[user*]/orcid_platform": {"fun": "load_from", "terms": "orcid_platform"}, + "/ENTRY[entry*]/USER[user*]/telephone_number": {"fun": "load_from", "terms": "telephone_number"}, + "/ENTRY[entry*]/USER[user*]/role": {"fun": "load_from", "terms": "role"}, + "/ENTRY[entry*]/USER[user*]/social_media_name": {"fun": "load_from", "terms": "social_media_name"}, + "/ENTRY[entry*]/USER[user*]/social_media_platform": {"fun": "load_from", "terms": "social_media_platform"}} + +NxDetectorListOfDict = {"/ENTRY[entry*]/em_lab/DETECTOR[detector*]/local_name": {"fun": "load_from", "terms": "local_name"}} + +# atom_types is a good example for specific cases where one cannot just blindly map +# the list that comes from the custom schema ELN instance, because +# people may enter invalid types of atoms (which would generate problems in NOMAD OASIS) +# and for NeXus we would like to have a "string of a comma-separated list of element names" + +NxSample = {"IGNORE": {"fun": "load_from", "terms": "sample/atom_types"}, + "/ENTRY[entry*]/sample/description": {"fun": "load_from", "terms": "sample/description"}, + "/ENTRY[entry*]/sample/method": {"fun": "load_from", "terms": "sample/method"}, + "/ENTRY[entry*]/sample/name": {"fun": "load_from", "terms": "sample/name"}, + "/ENTRY[entry*]/sample/preparation_date": {"fun": "load_from", "terms": "sample/preparation_date"}, + "/ENTRY[entry*]/sample/sample_history": {"fun": "load_from", "terms": "sample/sample_history"}, + "/ENTRY[entry*]/sample/short_title": {"fun": "load_from", "terms": "sample/short_title"}, + "/ENTRY[entry*]/sample/thickness": {"fun": "load_from", "terms": "sample/thickness/value"}, + "/ENTRY[entry*]/sample/thickness/@units": {"fun": "load_from", "terms": "sample/thickness/unit"}} diff --git a/pynxtools/dataconverter/readers/apm/reader.py b/pynxtools/dataconverter/readers/apm/reader.py index 651100fd1..729945c6b 100644 --- a/pynxtools/dataconverter/readers/apm/reader.py +++ b/pynxtools/dataconverter/readers/apm/reader.py @@ -23,22 +23,25 @@ from pynxtools.dataconverter.readers.base.reader import BaseReader -from pynxtools.dataconverter.readers.apm.utils.apm_use_case_selector \ +from pynxtools.dataconverter.readers.apm.utils.apm_define_io_cases \ import ApmUseCaseSelector -from pynxtools.dataconverter.readers.apm.utils.apm_generic_eln_io \ +from pynxtools.dataconverter.readers.apm.utils.apm_load_deployment_specifics \ + import NxApmNomadOasisConfigurationParser + +from pynxtools.dataconverter.readers.apm.utils.apm_load_generic_eln \ import NxApmNomadOasisElnSchemaParser -from pynxtools.dataconverter.readers.apm.utils.apm_reconstruction_io \ +from pynxtools.dataconverter.readers.apm.utils.apm_load_reconstruction \ import ApmReconstructionParser -from pynxtools.dataconverter.readers.apm.utils.apm_ranging_io \ +from pynxtools.dataconverter.readers.apm.utils.apm_load_ranging \ import ApmRangingDefinitionsParser -from pynxtools.dataconverter.readers.apm.utils.apm_nexus_plots \ +from pynxtools.dataconverter.readers.apm.utils.apm_create_nx_default_plots \ import apm_default_plot_generator -from pynxtools.dataconverter.readers.apm.utils.apm_example_data \ +from pynxtools.dataconverter.readers.apm.utils.apm_generate_synthetic_data \ import ApmCreateExampleData # this apm parser combines multiple sub-parsers @@ -103,6 +106,12 @@ def read(self, print("No input file defined for eln data !") return {} + print("Parse (meta)data coming from a configuration that specific OASIS...") + if len(case.cfg) == 1: + nx_apm_cfg = NxApmNomadOasisConfigurationParser(case.cfg[0], entry_id) + nx_apm_cfg.report(template) + # having and or using a deployment-specific configuration is optional + print("Parse (numerical) data and metadata from ranging definitions file...") if len(case.reconstruction) == 1: nx_apm_recon = ApmReconstructionParser(case.reconstruction[0], entry_id) diff --git a/pynxtools/dataconverter/readers/apm/utils/apm_nexus_plots.py b/pynxtools/dataconverter/readers/apm/utils/apm_create_nx_default_plots.py similarity index 100% rename from pynxtools/dataconverter/readers/apm/utils/apm_nexus_plots.py rename to pynxtools/dataconverter/readers/apm/utils/apm_create_nx_default_plots.py diff --git a/pynxtools/dataconverter/readers/apm/utils/apm_use_case_selector.py b/pynxtools/dataconverter/readers/apm/utils/apm_define_io_cases.py similarity index 75% rename from pynxtools/dataconverter/readers/apm/utils/apm_use_case_selector.py rename to pynxtools/dataconverter/readers/apm/utils/apm_define_io_cases.py index 2819281ba..6b02f3283 100644 --- a/pynxtools/dataconverter/readers/apm/utils/apm_use_case_selector.py +++ b/pynxtools/dataconverter/readers/apm/utils/apm_define_io_cases.py @@ -48,15 +48,21 @@ def __init__(self, file_paths: Tuple[str] = None): if suffix in self.supported_mime_types: if file_name not in self.case[suffix]: self.case[suffix].append(file_name) - recon_input = 0 - range_input = 0 + + recon_input = 0 # reconstruction relevant file e.g. POS, ePOS, APT + range_input = 0 # ranging definition file, e.g. RNG, RRNG + other_input = 0 # generic ELN or OASIS-specific configurations for mime_type, value in self.case.items(): if mime_type in ["pos", "epos", "apt"]: recon_input += len(value) - if mime_type in ["rrng", "rng", "txt"]: + elif mime_type in ["rrng", "rng", "txt"]: range_input += len(value) - eln_input = len(self.case["yaml"]) + len(self.case["yml"]) - if (recon_input == 1) and (range_input == 1) and (eln_input == 1): + elif mime_type in ["yaml", "yml"]: + other_input += len(value) + else: + continue + + if (recon_input == 1) and (range_input == 1) and (1 <= other_input <= 2): self.is_valid = True self.reconstruction: List[str] = [] self.ranging: List[str] = [] @@ -64,6 +70,12 @@ def __init__(self, file_paths: Tuple[str] = None): self.reconstruction += self.case[mime_type] for mime_type in ["rrng", "rng", "txt"]: self.ranging += self.case[mime_type] - self.eln: List[str] = [] + yml: List[str] = [] for mime_type in ["yaml", "yml"]: - self.eln += self.case[mime_type] + yml += self.case[mime_type] + for entry in yml: + if entry.endswith(".oasis.specific.yaml") \ + or entry.endswith(".oasis.specific.yml"): + self.cfg += [entry] + else: + self.eln += [entry] diff --git a/pynxtools/dataconverter/readers/apm/utils/apm_example_data.py b/pynxtools/dataconverter/readers/apm/utils/apm_generate_synthetic_data.py similarity index 99% rename from pynxtools/dataconverter/readers/apm/utils/apm_example_data.py rename to pynxtools/dataconverter/readers/apm/utils/apm_generate_synthetic_data.py index 47c63f8f3..c34d30f7b 100644 --- a/pynxtools/dataconverter/readers/apm/utils/apm_example_data.py +++ b/pynxtools/dataconverter/readers/apm/utils/apm_generate_synthetic_data.py @@ -45,7 +45,7 @@ from pynxtools.dataconverter.readers.apm.utils.apm_versioning \ import NX_APM_ADEF_NAME, NX_APM_ADEF_VERSION, NX_APM_EXEC_NAME, NX_APM_EXEC_VERSION -from pynxtools.dataconverter.readers.apm.utils.apm_ranging_io \ +from pynxtools.dataconverter.readers.apm.utils.apm_load_ranging \ import add_unknown_iontype diff --git a/pynxtools/dataconverter/readers/apm/utils/apm_load_deployment_specifics.py b/pynxtools/dataconverter/readers/apm/utils/apm_load_deployment_specifics.py new file mode 100644 index 000000000..309f31c7e --- /dev/null +++ b/pynxtools/dataconverter/readers/apm/utils/apm_load_deployment_specifics.py @@ -0,0 +1,60 @@ +# +# Copyright The NOMAD Authors. +# +# This file is part of NOMAD. See https://nomad-lab.eu for further info. +# +# Licensed under the Apache License, Version 2.0 (the "License"); +# you may not use this file except in compliance with the License. +# You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. +# +"""Load deployment specific quantities.""" + +# pylint: disable=no-member + +import flatdict as fd + +import numpy as np + +import yaml + +from pynxtools.dataconverter.readers.apm.map_concepts.apm_deployment_specifics_to_nx_map \ + import NxApmDeploymentSpecificInput + +from pynxtools.dataconverter.readers.shared.map_concepts.mapping_functors \ + import apply_modifier, variadic_path_to_specific_path + + +class NxApmNomadOasisConfigurationParser: # pylint: disable=too-few-public-methods + """Parse deployment specific configuration.""" + + def __init__(self, file_name: str, entry_id: int): + print(f"Extracting data from deployment specific configuration file: {file_name}") + if (file_name.rsplit('/', 1)[-1].endswith(".oasis.specific.yaml") + or file_name.endswith(".oasis.specific.yml")) and entry_id > 0: + self.entry_id = entry_id + self.file_name = file_name + with open(self.file_name, "r", encoding="utf-8") as stream: + self.yml = fd.FlatDict(yaml.safe_load(stream), delimiter="/") + else: + self.entry_id = 1 + self.file_name = "" + self.yml = {} + + def parse_other_sections(self, template: dict) -> dict: + """Copy data from configuration applying mapping functors.""" + for nx_path, modifier in NxApmDeploymentSpecificInput.items(): + if (nx_path != "IGNORE") and (nx_path != "UNCLEAR"): + trg = variadic_path_to_specific_path(nx_path, [self.entry_id, 1]) + res = apply_modifier(modifier, self.yml) + if res is not None: + template[trg] = res + + return template \ No newline at end of file diff --git a/pynxtools/dataconverter/readers/apm/utils/apm_generic_eln_io.py b/pynxtools/dataconverter/readers/apm/utils/apm_load_generic_eln.py similarity index 100% rename from pynxtools/dataconverter/readers/apm/utils/apm_generic_eln_io.py rename to pynxtools/dataconverter/readers/apm/utils/apm_load_generic_eln.py diff --git a/pynxtools/dataconverter/readers/apm/utils/apm_ranging_io.py b/pynxtools/dataconverter/readers/apm/utils/apm_load_ranging.py similarity index 100% rename from pynxtools/dataconverter/readers/apm/utils/apm_ranging_io.py rename to pynxtools/dataconverter/readers/apm/utils/apm_load_ranging.py diff --git a/pynxtools/dataconverter/readers/apm/utils/apm_reconstruction_io.py b/pynxtools/dataconverter/readers/apm/utils/apm_load_reconstruction.py similarity index 100% rename from pynxtools/dataconverter/readers/apm/utils/apm_reconstruction_io.py rename to pynxtools/dataconverter/readers/apm/utils/apm_load_reconstruction.py diff --git a/pynxtools/dataconverter/readers/apm/utils/apm_utils.py b/pynxtools/dataconverter/readers/apm/utils/apm_utils.py deleted file mode 100644 index f04c329ee..000000000 --- a/pynxtools/dataconverter/readers/apm/utils/apm_utils.py +++ /dev/null @@ -1,26 +0,0 @@ -# -# Copyright The NOMAD Authors. -# -# This file is part of NOMAD. See https://nomad-lab.eu for further info. -# -# Licensed under the Apache License, Version 2.0 (the "License"); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. -# -"""Set of utility tools for parsing file formats used by atom probe.""" - -# pylint: disable=no-member - -# ifes_apt_tc_data_modeling replaces now the previously here stored -# convenience functions which translated human-readable ion names into -# isotope_vector descriptions and vice versa as proposed by M. Kuehbach et al. in -# DOI: 10.1017/S1431927621012241 to the human-readable ion names which are use -# in P. Felfer et al."s atom probe toolbox diff --git a/pynxtools/dataconverter/readers/em_nion/concepts/README.md b/pynxtools/dataconverter/readers/em_nion/map_concepts/README.md similarity index 100% rename from pynxtools/dataconverter/readers/em_nion/concepts/README.md rename to pynxtools/dataconverter/readers/em_nion/map_concepts/README.md diff --git a/pynxtools/dataconverter/readers/em_nion/concepts/swift_display_items_to_nx_concepts.py b/pynxtools/dataconverter/readers/em_nion/map_concepts/swift_display_items_to_nx.py similarity index 100% rename from pynxtools/dataconverter/readers/em_nion/concepts/swift_display_items_to_nx_concepts.py rename to pynxtools/dataconverter/readers/em_nion/map_concepts/swift_display_items_to_nx.py diff --git a/pynxtools/dataconverter/readers/em_nion/concepts/generic_eln_mapping.py b/pynxtools/dataconverter/readers/em_nion/map_concepts/swift_eln_to_nx_map.py similarity index 100% rename from pynxtools/dataconverter/readers/em_nion/concepts/generic_eln_mapping.py rename to pynxtools/dataconverter/readers/em_nion/map_concepts/swift_eln_to_nx_map.py diff --git a/pynxtools/dataconverter/readers/em_nion/concepts/nx_image_ang_space.py b/pynxtools/dataconverter/readers/em_nion/map_concepts/swift_to_nx_image_ang_space.py similarity index 100% rename from pynxtools/dataconverter/readers/em_nion/concepts/nx_image_ang_space.py rename to pynxtools/dataconverter/readers/em_nion/map_concepts/swift_to_nx_image_ang_space.py diff --git a/pynxtools/dataconverter/readers/em_nion/concepts/nx_image_real_space.py b/pynxtools/dataconverter/readers/em_nion/map_concepts/swift_to_nx_image_real_space.py similarity index 100% rename from pynxtools/dataconverter/readers/em_nion/concepts/nx_image_real_space.py rename to pynxtools/dataconverter/readers/em_nion/map_concepts/swift_to_nx_image_real_space.py diff --git a/pynxtools/dataconverter/readers/em_nion/concepts/nx_spectrum_eels.py b/pynxtools/dataconverter/readers/em_nion/map_concepts/swift_to_nx_spectrum_eels.py similarity index 100% rename from pynxtools/dataconverter/readers/em_nion/concepts/nx_spectrum_eels.py rename to pynxtools/dataconverter/readers/em_nion/map_concepts/swift_to_nx_spectrum_eels.py diff --git a/pynxtools/dataconverter/readers/em_nion/reader.py b/pynxtools/dataconverter/readers/em_nion/reader.py index ac785fda3..e226aca91 100644 --- a/pynxtools/dataconverter/readers/em_nion/reader.py +++ b/pynxtools/dataconverter/readers/em_nion/reader.py @@ -23,10 +23,10 @@ from pynxtools.dataconverter.readers.base.reader import BaseReader -from pynxtools.dataconverter.readers.em_nion.utils.use_case_selector \ +from pynxtools.dataconverter.readers.em_nion.utils.swift_define_io_cases \ import EmNionUseCaseSelector -from pynxtools.dataconverter.readers.em_nion.utils.em_generic_eln_io \ +from pynxtools.dataconverter.readers.em_nion.utils.swift_load_generic_eln \ import NxEmNionElnSchemaParser from pynxtools.dataconverter.readers.em_nion.utils.swift_zipped_project_parser \ diff --git a/pynxtools/dataconverter/readers/em_nion/utils/versioning.py b/pynxtools/dataconverter/readers/em_nion/utils/em_nion_versioning.py similarity index 100% rename from pynxtools/dataconverter/readers/em_nion/utils/versioning.py rename to pynxtools/dataconverter/readers/em_nion/utils/em_nion_versioning.py diff --git a/pynxtools/dataconverter/readers/em_nion/utils/use_case_selector.py b/pynxtools/dataconverter/readers/em_nion/utils/swift_define_io_cases.py similarity index 100% rename from pynxtools/dataconverter/readers/em_nion/utils/use_case_selector.py rename to pynxtools/dataconverter/readers/em_nion/utils/swift_define_io_cases.py diff --git a/pynxtools/dataconverter/readers/em_nion/utils/swift_dimscale_axes.py b/pynxtools/dataconverter/readers/em_nion/utils/swift_generate_dimscale_axes.py similarity index 96% rename from pynxtools/dataconverter/readers/em_nion/utils/swift_dimscale_axes.py rename to pynxtools/dataconverter/readers/em_nion/utils/swift_generate_dimscale_axes.py index cdc15e895..fbd9cfcf2 100644 --- a/pynxtools/dataconverter/readers/em_nion/utils/swift_dimscale_axes.py +++ b/pynxtools/dataconverter/readers/em_nion/utils/swift_generate_dimscale_axes.py @@ -23,7 +23,7 @@ import numpy as np -from pynxtools.dataconverter.readers.em_nion.concepts.swift_display_items_to_nx_concepts \ +from pynxtools.dataconverter.readers.em_nion.map_concepts.swift_display_items_to_nx \ import metadata_constraints, check_existence_of_required_fields # nexus_concept_dict diff --git a/pynxtools/dataconverter/readers/em_nion/utils/em_generic_eln_io.py b/pynxtools/dataconverter/readers/em_nion/utils/swift_load_generic_eln.py similarity index 95% rename from pynxtools/dataconverter/readers/em_nion/utils/em_generic_eln_io.py rename to pynxtools/dataconverter/readers/em_nion/utils/swift_load_generic_eln.py index 8be648477..4028e4986 100644 --- a/pynxtools/dataconverter/readers/em_nion/utils/em_generic_eln_io.py +++ b/pynxtools/dataconverter/readers/em_nion/utils/swift_load_generic_eln.py @@ -27,16 +27,16 @@ from ase.data import chemical_symbols -from pynxtools.dataconverter.readers.em_nion.utils.versioning \ +from pynxtools.dataconverter.readers.em_nion.utils.em_nion_versioning \ import NX_EM_NION_ADEF_NAME, NX_EM_NION_ADEF_VERSION -from pynxtools.dataconverter.readers.em_nion.utils.versioning \ +from pynxtools.dataconverter.readers.em_nion.utils.em_nion_versioning \ import NX_EM_NION_EXEC_NAME, NX_EM_NION_EXEC_VERSION -from pynxtools.dataconverter.readers.em_nion.concepts.swift_handle_nx_concepts \ +from pynxtools.dataconverter.readers.shared.map_concepts.mapping_functors \ import apply_modifier, variadic_path_to_specific_path -from pynxtools.dataconverter.readers.em_nion.concepts.generic_eln_mapping \ +from pynxtools.dataconverter.readers.em_nion.map_concepts.swift_eln_to_nx_map \ import NxEmElnInput, NxUserFromListOfDict, NxDetectorListOfDict, NxSample diff --git a/pynxtools/dataconverter/readers/em_nion/utils/swift_zipped_project_parser.py b/pynxtools/dataconverter/readers/em_nion/utils/swift_zipped_project_parser.py index f72f7d48c..17f74ba61 100644 --- a/pynxtools/dataconverter/readers/em_nion/utils/swift_zipped_project_parser.py +++ b/pynxtools/dataconverter/readers/em_nion/utils/swift_zipped_project_parser.py @@ -38,21 +38,21 @@ from pynxtools.dataconverter.readers.em_nion.utils.swift_uuid_to_file_name \ import uuid_to_file_name -from pynxtools.dataconverter.readers.em_nion.utils.swift_dimscale_axes \ +from pynxtools.dataconverter.readers.em_nion.utils.swift_generate_dimscale_axes \ import get_list_of_dimension_scale_axes -from pynxtools.dataconverter.readers.em_nion.concepts.swift_display_items_to_nx_concepts \ +from pynxtools.dataconverter.readers.em_nion.map_concepts.swift_display_items_to_nx \ import nexus_concept_dict, identify_nexus_concept_key -from pynxtools.dataconverter.readers.em_nion.concepts.swift_handle_nx_concepts \ +from pynxtools.dataconverter.readers.shared.map_concepts.mapping_functors \ import apply_modifier, variadic_path_to_specific_path -from pynxtools.dataconverter.readers.em_nion.concepts.nx_image_real_space \ +from pynxtools.dataconverter.readers.em_nion.map_concepts.swift_to_nx_image_real_space \ import NxImageRealSpaceDict -from pynxtools.dataconverter.readers.em_nion.utils.versioning \ +from pynxtools.dataconverter.readers.em_nion.utils.em_nion_versioning \ import NX_EM_NION_SWIFT_NAME, NX_EM_NION_SWIFT_VERSION -from pynxtools.dataconverter.readers.em_nion.utils.versioning \ +from pynxtools.dataconverter.readers.em_nion.utils.em_nion_versioning \ import NX_EM_NION_EXEC_NAME, NX_EM_NION_EXEC_VERSION diff --git a/pynxtools/dataconverter/readers/em_nion/concepts/swift_handle_nx_concepts.py b/pynxtools/dataconverter/readers/shared/map_concepts/mapping_functors.py similarity index 100% rename from pynxtools/dataconverter/readers/em_nion/concepts/swift_handle_nx_concepts.py rename to pynxtools/dataconverter/readers/shared/map_concepts/mapping_functors.py diff --git a/pynxtools/definitions b/pynxtools/definitions index e0079c9a4..e445bf59f 160000 --- a/pynxtools/definitions +++ b/pynxtools/definitions @@ -1 +1 @@ -Subproject commit e0079c9a4a3d40d041c27f29415e5250590769a9 +Subproject commit e445bf59fcf547eb0699580e46523ba9f47b2cca diff --git a/pynxtools/nyaml2nxdl/NXapm.nxdl.xml b/pynxtools/nyaml2nxdl/NXapm.nxdl.xml new file mode 100644 index 000000000..4d991f59a --- /dev/null +++ b/pynxtools/nyaml2nxdl/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/pynxtools/nyaml2nxdl/NXapm.yaml b/pynxtools/nyaml2nxdl/NXapm.yaml new file mode 100644 index 000000000..30729bdf1 --- /dev/null +++ b/pynxtools/nyaml2nxdl/NXapm.yaml @@ -0,0 +1,1548 @@ +category: application +doc: | + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. +symbols: + doc: The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: Total number of ions collected. + n_dld_wires: Total number of independent wires in the delay-line detector. + n_support: Number of support points for e.g. modeling peaks. + n_ivec_max: | + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + n_ranges: | + Number of mass-to-charge-state-ratio intervals of this ion type. + n_x: Number of bins in the x direction. + n_y: Number of bins in the y direction. + n_z: Number of bins in the z direction. + n_bins: Number of bins. + n_topology: Total number of integers in the supplementary XDMF topology array. +# some consistence is not yet achieved with IFES_APT_TC APT HDF5 v1 format +# Language precision: Keywords such as “must” “required” “should”, etc are as per RFC-2119 [RFC2119]. https://tools.ietf.org/html/rfc2119 +# https://gitlab.com/apt_software_toolbox/apt-hdf5 an implementation for an +# IFES APT TC APT HDF5 v1 verifier +# NEW ISSUE: possible offspring application definitions: +# NXapm_opt/pl would be possible, as soon as NXluminescence by Carola Emminger and Florian Dobner is ready whereby +# then there would be two subentries one for an NXapm and one for NXphotoluminesence to capture the photonic atom probe of Rouen/GPM +# and finally if there were an NXapm_afm for atomic force microscopy the IMEC AFM/APT experiments could be stored with an NXapm_afm application definition +# with NXapm and NXafm being respective subentries of the appdef but as NXapm_afm is a step-by-step approach one would have to release the constraint +# that only a single measurement can be performed. +# NXasat which could just take two subentries NXem and NXapm +# NXasat should be a fuse of NXapm and NXem within an NXentry with NXsubentry, in this way we can combine the strength of both application definitions +# to describe also the upcoming technique of atomic scale analytical tomography https://doi.org/10.1017/9781316677292 + +NXapm: + (NXentry): + exists: [min, 1, max, infty] + \@version: + doc: | + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + # enumeration: [sha_256_hash] + definition: + doc: NeXus NXDL schema to which this file conforms. + enumeration: [NXapm] + experiment_identifier: + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + experiment_description: + exists: optional + doc: | + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + # These computations can take advantage of individual time stamps + # in NXevent_em instances to provide additional pieces of information. + end_time(NX_DATE_TIME): + exists: recommended + doc: | + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + # NEW ISSUE: fields like duration need a clearer description as to how these + # quantities should be defined. Most atom probers do not care for this other + # than getting an approximate hour-accurate estimate of the time how long it + # took to evaporate the specimen. + # several programs and libraries are usually coupled together for LEAP instruments, + # if it is possible to have a different root version with a different ivas/apsuite + # version that having a single program and version field is not enough but multiple + # are required LAS root version camecaroot version analysis software + + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: + run_number: + exists: recommended + doc: | + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + experiment_documentation(NXnote): + exists: optional + doc: | + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + thumbnail(NXnote): + exists: optional + doc: | + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + \@type: + operation_mode: + doc: | + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + enumeration: [apt, fim, apt_fim, other] + # description: + # exists: optional + # doc: | + (NXuser): + exists: [min, 0, max, infty] + doc: | + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + name: + doc: Given (first) name and surname of the user. + affiliation: + exists: recommended + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address: + exists: recommended + doc: Postal address of the affiliation. + email: + exists: recommended + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + orcid: + exists: recommended + doc: | + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + orcid_platform: + exists: recommended + doc: | + Name of the OrcID or ResearcherID where the account + under orcid is registered. + telephone_number: + exists: optional + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role: + exists: recommended + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + social_media_name: + exists: optional + doc: | + Account name that is associated with the user + in social media platforms. + social_media_platform: + exists: optional + doc: | + Name of the social media platform where the account + under social_media_name is registered. + sample(NXsample): + exists: recommended + doc: | + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + grain_diameter(NX_FLOAT): + exists: optional + doc: | + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + unit: NX_LENGTH + grain_diameter_error(NX_FLOAT): + exists: optional + doc: | + Magnitude of the standard deviation of the grain_diameter. + unit: NX_LENGTH + heat_treatment_temperature(NX_FLOAT): + exists: optional + doc: | + The temperature of the last heat treatment step before quenching. + Knowledge about this value can give an idea how the sample + was heat treated, however if available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + unit: NX_TEMPERATURE + heat_treatment_temperature_error(NX_FLOAT): + exists: optional + doc: | + Magnitude of the standard deviation of the heat_treatment_temperature. + unit: NX_TEMPERATURE + heat_treatment_quenching_rate(NX_FLOAT): + exists: optional + doc: | + Rate of the last quenching step. + Knowledge about this value can give an idea how the specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + unit: NX_ANY + heat_treatment_quenching_rate_error(NX_FLOAT): + exists: optional + doc: | + Magnitude of the standard deviation of the heat_treatment_quenching_rate. + unit: NX_ANY + description: + exists: optional + (NXchemical_composition): + exists: recommended + doc: | + The chemical composition of the sample. Typically it is assumed that + this more macroscopic composition is representative for the material + so that the composition of the typically substantially less voluminous + specimen probes from the more voluminous sample. + normalization: + doc: | + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + enumeration: [atom_percent, weight_percent] + ION(NXion): + exists: [min, 1, max, 118] + name: + doc: | + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + composition(NX_FLOAT): + doc: | + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + unit: NX_DIMENSIONLESS + composition_error(NX_FLOAT): + doc: | + Magnitude of the standard deviation of the composition (value). + unit: NX_DIMENSIONLESS + specimen(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # NEW ISSUE: addition of a NXfurnace in which one can define the atmosphere + # and partial pressures of the agents in that atmosphere with which the + # sample was annealed at which temperature see the work happening at PNNL + # NEW ISSUE: it would be good to have an application definition NXicp for chemical composition + name: + doc: | + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + sample_history: + exists: recommended + doc: | + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + preparation_date(NX_DATE_TIME): + exists: recommended + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + alias: + exists: optional + doc: | + Short_name or abbreviation of the specimen name field. + atom_types: + doc: | + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + description: + exists: optional + doc: | + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + is_polycrystalline(NX_BOOLEAN): + exists: recommended + doc: | + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + # NEW ISSUE: error model + # NEW ISSUE: use Andrea and MarkusK groups for + # describing the geometry of the sample + (NXdata): + exists: optional + doc: | + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + (NXcoordinate_system_set): + exists: recommended + doc: | + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + # Spatial transformations are always active transformations; i.e. the location and direction of a vector in one coordinate system is expressed by the following transformation matrix, T Ptransformed = TPoriginal + # add a note about what is the tip space + #Conventions: right-handed, Cartesian, 3D Euclidean CS should be used Laboratory space to be set by This is the space that is set by the chassis of the instrument. The Z direction must be reasonably parallel to gravity (+ve defined to be gravity vector pointing towards lowest ground), but can be defined to be a direction that is nominally parallel to gravity during an experiment. The origin must be placed within a bounding box of the chassis. Tip space instead of specimen space, The space occupied by a tip in the neutral position when ready for analysis. Z+ should be located in the direction of the needle (apex is Z+ from needle centreline). i) If the specimen moves relative to the laboratory frame, and the electrode does not, or if no electrode is present, then the space should be defined such that when the tip is moved physically, it also moves through tip space. ii) If the electrode moves relative to the laboratory frame, then the space should be defined such that, in tip space, the electrode position does not change. + # iii) The transformation between laboratory space and Tip space must be describable by a fixed 3x3 transformation matrix. Detector space: This is a 2D space only, and contains X+ and Y+ directions. X+ and Y+ should indicate primary directions on the detector, and should be, for an equivalent straight-flight-path configuration, such that X+ and Y+ is matched to that of tip space. Laser space missing: Laser space: The coordinate frame describing the impinging wavefront on the sample. Z+ is the vector of the propagating wavefront. X+ is the orthogonal component of the tip direction within the tip-laser plane. The origin shall be placed at the best estimate for tip apex position at the start of the experiment. Reconstruction space : The space occupied by a correctly reconstructed dataset. X+ and Y+ should correspond to X+ and Y+ in the detector space. Z+ should be such that the needle centre line is normal to the detector position. The origin shall be placed at the tip apex. + TRANSFORMATIONS(NXtransformations): + exists: [min, 0, max, infty] + # NEW ISSUE: add Breen's Ultramicroscopy paper on atom probe crystallography + # in what follows each component of the instrument might be equipped with an NXmonitor + (NXmonitor): + exists: [min, 0, max, infty] + # NEW ISSUE ADD AS MANY MONITORS AS NEEDED, also for pressure etc. + # add a default plot V = f(time/evaporation_id), essentially for each quantity + atom_probe(NXinstrument): + doc: | + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + (NXcsg): + exists: optional + instrument_name: + doc: | + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + location: + exists: optional + doc: | + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + (NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + capabilities: + exists: optional + flight_path_length(NX_FLOAT): + doc: | + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + unit: NX_LENGTH + # NEW ISSUE: discussion depends on the type of instrument, + # straight flight path, curved, there were a few comments to made + # https://fairmat-experimental.github.io/nexus-fairmat-proposal/ + # 50433d9039b3f33299bab338998acb5335cd8951/classes/ + # contributed_definitions/NXapm.html + # where further details of the flight geometry should be recorded however + # in the majority of cases these data are not offered by APSuite and + # so far nobody has asked or seriously proceeded with how to use these + # pieces of information if they were to be stored + # MK::NEW ISSUE + field_of_view(NX_FLOAT): + exists: recommended + doc: | + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + unit: NX_LENGTH + (NXreflectron): + # check if doc string gets carried over doc: Device for reducing flight time differences of ions in ToF experiments. + applied(NX_BOOLEAN): + doc: | + Is a reflectron installed and was it used? + name: + exists: optional + (NXfabrication): + exists: optional + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + capabilities: + exists: optional + description: + exists: recommended + (NXcsg): + exists: optional + # NEW ISSUE: flat_test_data(NXcollection): + # exists: recommended + # doc: NEED FOR FURTHER DISCUSSIONS WITH APM COLLEAGUES WHAT IS RELEVANT HERE. + # NEW ISSUE: have a place to be more specific about the geometry and + # usage of additional lenses: + # for the invizo 6000 instrument it makes sense to add at least groups for the two additional lenses whereby the field of view is brought from 50-60 to at most 100 the key invention + # add: decelerating_electrode(NXlens_em) accelerating_mesh maybe needs an own base class + # I suggest that this section should be reworked with the local_electrode being required and all other components and opposite counter_electrodes being optional WO2016171675A1 details the key specifications of the components and the setup + # see https://en.wikipedia.org/wiki/Einzel_lens for details double einzel lens in the invizo 6000 according to A. Breen (UNSW) + local_electrode(NXlens_em): + doc: | + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + name: + doc: | + Identifier of the local_electrode in an e.g. database. + (NXaperture_em): + exists: optional + name: + exists: recommended # ##MK::should become required + (NXfabrication): + exists: optional + identifier: + exists: recommended + capabilities: + exists: optional + value(NX_NUMBER): + exists: recommended # ##MK::should become required + (NXcsg): + exists: optional + # but the local_electrode does not really on purpose create a magnetic field, + # specific for an electro-magnetic lens is the symmetry of its field + # NEW ISSUE: for now keep that we have what is an NXlens_em + # NEW ISSUE: APEX MONITOR / LEAP distance monitoring + # NEW ISSUE: the definition of flat test data should be included and documented + # NEW ISSUE: local electrode, baking strategies, storage + ion_detector(NXdetector): + doc: | + Detector for taking raw time-of-flight and + ion/hit impact positions data. + type: + doc: | + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + # enumeration: [mcp_dld, phosphor_ccd, other] + name: + exists: recommended + doc: Given name/alias. + # NEW ISSUE: why not (NXfabrication) + model: + exists: recommended + doc: Given brand or model name by the manufacturer. + serial_number: + exists: recommended + doc: | + Given hardware name/serial number or hash identifier + issued by the manufacturer. + manufacturer_name: + exists: recommended + doc: Given name of the manufacturer. + signal_amplitude(NX_FLOAT): + exists: optional + doc: | + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + unit: NX_CURRENT + dimensions: + rank: 1 + dim: [[1, n_ions]] + (NXcsg): + exists: optional + pulser(NXpulser_apm): + # NEW ISSUE: other sources of pulsers are possible + # NEW ISSUE: see in WO2016171675A1 Invizo 6000 patent from AMETEK + pulse_mode: + pulse_frequency(NX_FLOAT): + pulse_fraction(NX_FLOAT): + pulsed_voltage(NX_FLOAT): + exists: recommended + standing_voltage(NX_FLOAT): + exists: recommended + (NXcsg): + exists: optional + SOURCE(NXsource): + exists: [min, 0, max, 2] + # INVIZO 6000 instrument have two symmetric lasers! so for these + # laser_gun and laser_beam exists: [min, 0, max, 2] + doc: | + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + name: + (NXfabrication): + exists: optional + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + capabilities: + exists: optional + wavelength(NX_FLOAT): + exists: recommended + power(NX_FLOAT): + exists: recommended + pulse_energy(NX_FLOAT): + exists: recommended + laser_beam(NXbeam): + exists: recommended + pinhole_position(NXcollection): # NXsnapshot, NXcg_point_set + exists: recommended + spot_position(NXcollection): # NXsnapshot, NXcg_point_set + exists: recommended + + stage_lab(NXstage_lab): + # NEW ISSUE: consider more detailed opportunities for specifying holders like cryo-controller holder, type of holder, material for pucks make a difference for studies which hunt for hydrogen signal, equally dwell time in buffer and load lock chamber and environmental transfer, the application definition does not account for this at the moment, would need a class representing stage and specimen holder hierarchy of the entire sample loading and transfer system and the contributions or not these components make wrt to contamination. + base_temperature(NX_FLOAT): + doc: | + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + unit: NX_TEMPERATURE + temperature(NX_FLOAT): + exists: optional + doc: | + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + unit: NX_TEMPERATURE + dimensions: + rank: 1 + dim: [[1, n_ions]] + (NXcsg): + exists: optional + # evaporation control in which context is it used? + # NEW ISSUE: begin add and support I/O of further details + # NEW ISSUE: with Shyam Katnagallu fix that so far the application definition does not really cover fim as there is no place to store values for a gas injection system and a (partial) pressure sensor for the imaging gas it should be clarified in the docstring of the pressure field if this measured either a chamber total of a species partial pressure + # NEW ISSUE: add NXapm_energy_analyzer, a voltage grid like done in Rouen/GPM + analysis_chamber(NXchamber): + name: + exists: optional + (NXfabrication): + exists: optional + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + capabilities: + exists: optional + description: + exists: optional + pressure(NX_FLOAT): + doc: | + Average pressure in the analysis chamber. + unit: NX_PRESSURE + (NXcsg): + exists: optional + buffer_chamber(NXchamber): + exists: optional + name: + exists: optional + (NXfabrication): + exists: optional + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + capabilities: + exists: optional + description: + exists: optional + pressure(NX_FLOAT): + doc: | + Average pressure in the buffer chamber. + unit: NX_PRESSURE + (NXcsg): + exists: optional + load_lock_chamber(NXchamber): + exists: optional + name: + exists: optional + (NXfabrication): + exists: optional + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + capabilities: + exists: optional + description: + exists: optional + pressure(NX_FLOAT): + doc: | + Average pressure in the load_lock_chamber. + unit: NX_PRESSURE + (NXcsg): + exists: optional + getter_pump(NXpump): + exists: optional + design: + exists: recommended + (NXfabrication): + exists: optional + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + capabilities: + exists: optional + (NXcsg): + exists: optional + roughening_pump(NXpump): + exists: optional + design: + exists: recommended + (NXfabrication): + exists: optional + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + capabilities: + exists: optional + (NXcsg): + exists: optional + turbomolecular_pump(NXpump): + exists: optional + design: + exists: recommended + (NXfabrication): + exists: optional + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + capabilities: + exists: optional + (NXcsg): + exists: optional + # NEW ISSUE: end add and support I/O of further details + + instrument_calibration(NXcollection): + exists: recommended + doc: | + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group `_ + (see `P. Felfer et al. `_ ) + # gridded-counter-electrode shadow image polyline fits are exported as + # NXcg_spline_set see also https://www.youtube.com/watch?v=99hNEkqdj78t=2348s + # NEW ISSUE: dld_signal_amplitude monitoring + # arrival_time_pairs: (recommended) NX_NUMBER (Rank: 3, Dimensions: [n_ions, n_dld_wires, 2]) {units=NX_TIME} + # eventually one may wish to store values from an NXmonitoring tracking the DLD signal amplitude (mV) = f(t) + specimen_monitoring(NXcollection): + exists: recommended + # NEW ISSUE: should be promoted to recommended at some point in particular with closer integration of APM and EM instruments + doc: | + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. `_ + and `C. Fletcher `_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann `_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. `_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + # NEW ISSUE: consider the above comments into new fields when important progress has been made. + initial_radius(NX_FLOAT): + doc: | + Ideally measured or best elaborated guess of the + initial radius of the specimen. + unit: NX_LENGTH + shank_angle(NX_FLOAT): + doc: | + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + unit: NX_ANGLE + detection_rate(NX_FLOAT): + doc: | + Average detection rate over the course of the experiment. + unit: NX_DIMENSIONLESS + # NEW ISSUE: define e.g. radius(NX_FLOAT) and evaporation_id(NX_UINT) to store snapshots of the shape evolution of the specimen. + estimated_field_at_the_apex(NX_FLOAT): + exists: optional + doc: | + Estimated field at the apex along the evaporation sequence. + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, n_ions]] + + control_software(NXcollection): + doc: | + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) `_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + # NEW ISSUE: With new development pull fields out of this collection into dedicated groups. + # might consider moving this to individual groups under (NXpump) or (NXchamber) groups. + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: + buffer_chamber(NXcollection): + exists: optional + doc: Track time-dependent details over the course of the measurement about the buffer_chamber. + load_lock_chamber(NXcollection): + exists: optional + doc: Track time-dependent details over the course of the measurement about the load_lock_chamber. + analysis_chamber(NXcollection): + exists: optional + doc: Track time-dependent details over the course of the measurement about the analysis_chamber. + # NEW ISSUE: pressure in the buffer and load lock chambers + # NEW ISSUE: atmosphere and partial pressures + + # so although strictly speaking the following steps are computational + # post-processing of detector raw data to be specific they are listed + # under the atom_lab group because for experiment with commercial instrument + # these steps are currently not fully separatable as all processing in + # most cases the processing is done in commercial software. + + status: + exists: recommended + doc: | + A statement whether the measurement was successful or failed prematurely. + enumeration: [success, failure, unknown] + + # NEW ISSUE: atomic volume, detection efficiency, electric field (assumptions), + # final specimen state, pre, post image analysis, a reference to three images + # taken as recommended by cameca, before or after, radius evolution model, field # factor, image compression + + # default statistics would be good to report as output e.g. + # total ions (single, multiple, partial) reconstructed ions (ranged, unranged) + # voltage and bowl calibration (peak) mass_calibration as an own field + + ion_impact_positions(NXprocess): + # NEW ISSUE: check also here the PYCCAPT pipeline from P. Felfer's group + exists: recommended + doc: | + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: + arrival_time_pairs(NX_NUMBER): + exists: recommended + doc: | + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + # NEW ISSUE: discuss with Oxcart developers which + # modifications might be necessary here. + unit: NX_TIME + dimensions: + rank: 3 + dim: [[1, n_ions], [2, n_dld_wires], [3, 2]] + hit_positions(NX_NUMBER): + doc: | + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_ions], [2, 2]] + # NEW ISSUE: follow the example of base_temperature_time_profile to monitor the temporal evolution of the detection_rate over the course of the evaporation sequence + # detection_rate_time_profile(NX_FLOAT): + # doc: Spatio-temporal profile of the detection rate since the start of the measurement. + # NEW ISSUE: discuss how to handle cases when we would like to store ideally an array where one dimensions is NX_TIME and the other one is e.g. NX_PERCENT + hit_quality_filtering(NXprocess): + exists: optional + doc: | + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + sequence_index(NX_POSINT): + exists: recommended + hit_multiplicity(NXprocess): + # NEW ISSUE: use symbols to monitor number of pulses + exists: recommended + doc: | + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: + pulses_since_last_ion(NX_UINT): + exists: recommended + doc: | + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + dimensions: + rank: 1 + dim: [[1, n_ions]] + unit: NX_UNITLESS + pulse_id(NX_UINT): + # NEW ISSUE: I feel the name is misleading, the quantity is + # named like this de facto only because thats the jargon + # term with epos files. + exists: optional + doc: | + Number of pulses since the start of the atom probe + run/evaporation sequence. + dimensions: + rank: 1 + dim: [[1, n_ions]] + unit: NX_UNITLESS + hit_multiplicity(NX_UINT): + # NEW ISSUE: further discussions with members of the APM community + # is required to clarify this field and what it means + doc: | + Hit multiplicity. + dimensions: + rank: 1 + dim: [[1, n_ions]] + unit: NX_UNITLESS + ion_filtering(NXprocess): + exists: recommended + doc: | + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: + evaporation_id_included(NX_BOOLEAN): # NXcs_filter_boolean_mask + doc: | + Bitmask which is set to true if the ion + is considered and false otherwise. + dimensions: + rank: 1 + dim: [[1, n_ions]] # then only a group + + voltage_and_bowl_correction(NXprocess): + # NEW ISSUE: add section for propagation_delay(NXprocess) ? + exists: recommended + doc: | + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: + # NEW ISSUE: realistic is that currently scientists can pull always a calibrated time-of-flight + # but not necessarily unprocessed timing data from the detector (unless individuals built the instrument). + # Relevant for ranging are the calibrated data, thats why only these + # (as an intermediate/compromise solution) are required in this version of the application definition + raw_tof(NX_FLOAT): + exists: recommended + doc: | + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + unit: NX_TIME + dimensions: + rank: 1 + dim: [[1, n_ions]] + calibrated_tof(NX_FLOAT): + # NEW ISSUE: which type of calibrations are applied is usually a modified + # sqrt tof to m/q mapping the exact parameter of which are for LEAP instruments not immediately accessible. + doc: | + Calibrated time-of-flight. + unit: NX_TIME + dimensions: + rank: 1 + dim: [[1, n_ions]] + tof_calibration(NXcollection): + exists: recommended + doc: | + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + # NEW ISSUE: should be recommended as otherwise one cannot ensure that + # numerically the same voltage-and-bowl correction results are obtained + # (without knowning the parameters...) + + mass_to_charge_conversion(NXprocess): + exists: recommended + doc: | + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: + parameter(NXcollection): + exists: recommended + doc: | + Store vendor-specific calibration models here (if available). + mass_to_charge(NX_FLOAT): + doc: | + Mass-to-charge-state ratio values. + unit: NX_ANY + # \@units: Da / a unitless quantity because it is the charge state and not the charge + dimensions: + rank: 1 + dim: [[1, n_ions]] + + # NEW ISSUE: make this rather an own subentry NXapm_reconstruction + reconstruction(NXprocess): + exists: recommended + doc: | + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: + protocol_name: + doc: | + Qualitative statement about which reconstruction protocol was used. + enumeration: [bas, geiser, gault, cameca, other] + parameter: + # NEW ISSUE: the status here should be promoted to required but currently + # one needs to manually extract the reconstruction parameters + # NEW ISSUE: for instance from commercial software, here a better strategy + # is needed how to document the reconstruction parameter. + doc: | + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + # k(NX_FLOAT): + # doc: Field factor + # unit: ?? + # icf(NX_FLOAT): + # doc: Image compression factor. + # unit: ?? + # NEW ISSUE: for AMETEK, as well as for the Bas, Geiser, and + # Gault protocols we know the usual naming of the parameters + # they should be added as optional quantities. + # Therefore, it is difficult for now to generalize the meaning + # and idea behind all relevant reconstruction parameters. + # One could create a class for each reconstruction method, as + # these methods are de facto application definitions. + crystallographic_calibration: + doc: | + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + reconstructed_positions(NX_FLOAT): + doc: | + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_ions], [2, 3]] + visualization(NXprocess): + exists: recommended + xdmf_topology(NX_UINT): + doc: | + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_topology]] + # n_topology == 3*n_ions + xdmf_topology(NX_UINT): + doc: | + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, 36]] + + naive_point_cloud_density_map(NXprocess): + doc: | + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: + (NXdata): + doc: | + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + \@signal: + \@axes: + \@AXISNAME_indices: + # \@long_name: + title: + data_counts(NX_NUMBER): + doc: Array of counts for each bin. + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_z], [2, n_y], [3, n_x]] + axis_z(NX_FLOAT): + doc: Bin center of mass position along the z axis. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_z]] + \@long_name: + axis_y(NX_FLOAT): + doc: Bin center of mass position along the y axis. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + axis_x(NX_FLOAT): + doc: Bin center of mass position along the x axis. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + + # NEW ISSUE: make this rather an own subentry NXapm_ranging + ranging(NXprocess): + exists: recommended + doc: | + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller `_ + * `D. Haley et al. `_ + * `M. Kühbach et al. `_ + + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: + number_of_ion_types(NX_UINT): + doc: | + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + unit: NX_UNITLESS + maximum_number_of_atoms_per_molecular_ion(NX_UINT): + doc: | + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + unit: NX_UNITLESS + + mass_to_charge_distribution(NXprocess): + exists: recommended + doc: | + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: + range_minmax(NX_FLOAT): + doc: | + Smallest and largest mass-to-charge-state ratio value. + unit: NX_ANY + # \@units: Da + # NEW ISSUE: NX_ATOMIC_MASS_UNIT use Tommasso scheme here Da + dimensions: + rank: 1 + dim: [[1, 2]] + range_increment(NX_FLOAT): + doc: | + Binning width of the mass-to-charge-state ratio values. + unit: NX_ANY + # \@units: Da + # NEW ISSUE: unit must match with range, is Da + mass_spectrum(NXdata): + doc: | + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + \@signal: + \@axes: + \@AXISNAME_indices: + # \@long_name: + title: + data_counts(NX_NUMBER): + doc: Array of counts for each bin. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_bins]] + \@long_name: + axis_mass_to_charge(NX_FLOAT): + doc: | + Right boundary of each mass-to-charge-state ratio value bin. + unit: NX_ANY + # \@units: Da + dimensions: + rank: 1 + dim: [[1, n_bins]] + \@long_name: + + background_quantification(NXprocess): + exists: recommended + doc: | + Details of the background model which was used to + correct the total counts per bin into counts. + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: + # NEW ISSUE: add parameters of the background model in an e.g. + # NXcollection as these are specific to every background model + # NEW ISSUE: touching upon i.e. research activities by Andrew London et al. + # substantiating the need for a clearer description how peak/signals were + # eventually processed via deconvolution methods + + peak_search_and_deconvolution(NXprocess): + exists: recommended + doc: | + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: + (NXpeak): + exists: [min, 0, max, infty] + label: + exists: recommended + peak_model: + doc: | + THIS DOCSTRING NEEDS CLARIFICATION. + + peak_identification(NXprocess): + exists: recommended + doc: | + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: + (NXion): + exists: [min, 0, max, 256] + isotope_vector(NX_UINT): + charge_state(NX_INT): + mass_to_charge_range(NX_FLOAT): + nuclid_list(NX_UINT): + exists: recommended + name: + exists: recommended diff --git a/tests/data/dataconverter/readers/apm/nomad_oasis_eln_schema_for_nx_apm/nxapm.schema.archive.yaml b/tests/data/dataconverter/readers/apm/nomad_oasis_eln_schema_for_nx_apm/nxapm.schema.archive.yaml index a750d3a80..e27a61167 100644 --- a/tests/data/dataconverter/readers/apm/nomad_oasis_eln_schema_for_nx_apm/nxapm.schema.archive.yaml +++ b/tests/data/dataconverter/readers/apm/nomad_oasis_eln_schema_for_nx_apm/nxapm.schema.archive.yaml @@ -18,8 +18,7 @@ definitions: # This would be useful to make the default values set in `template` fixed. # Leave the hide key even if you want to pass an empty list like in this example. eln: - # hide: ['nxdl', 'reader'] - hide: [] + hide: ['nxdl', 'reader'] sub_sections: entry: section: @@ -29,24 +28,6 @@ definitions: eln: overview: true quantities: - attr_version: - type: - type_kind: Enum - type_data: - - 'nexus-fairmat-proposal successor of 9636feecb79bb32b828b1a9804269573256d7696' - description: Hashvalue of the NeXus application definition file - m_annotations: - eln: - component: RadioEnumEditQuantity - definition: - type: - type_kind: Enum - type_data: - - NXapm - description: NeXus NXDL schema to which this file conforms - m_annotations: - eln: - component: RadioEnumEditQuantity experiment_identifier: type: str description: GUID of the experiment @@ -58,40 +39,31 @@ definitions: description: Free text details about the experiment m_annotations: eln: - component: StringEditQuantity + component: RichTextEditQuantity start_time: type: Datetime - description: ISO 8601 time code with local time zone offset to UTC when the experiment started. + description: | + ISO 8601 time code with local time zone offset + to UTC when the experiment started. m_annotations: eln: component: DateTimeEditQuantity end_time: type: Datetime - description: ISO 8601 time code with local time zone offset to UTC when the experiment ended. + description: | + ISO 8601 time code with local time zone offset + to UTC when the experiment ended. m_annotations: eln: component: DateTimeEditQuantity - program: - type: str - description: Name of the program used to create this file. - m_annotations: - eln: - component: StringEditQuantity - program__attr_version: - type: str - description: Version plus build number, commit hash, or description of the program to support reproducibility. - m_annotations: - eln: - component: StringEditQuantity run_number: type: str - description: Identifier in the instrument control software given for this experiment. + description: | + Identifier in the instrument control software + given for this experiment. m_annotations: eln: component: StringEditQuantity - # experiment_documentation(NXnote): - # thumbnail(NXnote): - # attr_type: operation_mode: type: type_kind: Enum @@ -124,6 +96,173 @@ definitions: # m_annotations: # eln: # component: FileEditQuantity + + sample: + section: + description: | + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + m_annotations: + eln: + quantities: + composition: + type: str + shape: ['*'] + description: | + Chemical composition of the sample. The composition from e.g. + a composition table can be added as individual strings. + One string for each element with statements separated via a + single space. The string is expected to have the following format: + Symbol value unit +- stdev + + An example: B 1. +- 0.2, means + composition of boron 1. at.-% +- 0.2 at.%. + If a string contains only a symbol this is interpreted + that the symbol specifies the matrix or remainder element + for the composition table. + + If unit is omitted or named % this is interpreted as at.-%. + Unit can be at% or wt% but all strings have to use either atom + or weight percent but no mixtures. + No unit for stdev should be repeated as it has to be the + same unit as is used for the composition value. + m_annotations: + eln: + component: StringEditQuantity + grain_diameter: + type: np.float64 + unit: micrometer + description: | + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + m_annotations: + eln: + component: NumberEditQuantity + minValue: 0.0 + defaultDisplayUnit: micrometer + grain_diameter_error: + type: np.float64 + unit: micrometer + description: | + Magnitude of the standard deviation to the grain_diameter. + m_annotations: + eln: + component: NumberEditQuantity + minValue: 0.0 + defaultDisplayUnit: micrometer + heat_treatment_temperature: + type: np.float64 + unit: kelvin + description: | + The temperature of the last heat treatment step before quenching. + m_annotations: + eln: + component: NumberEditQuantity + minValue: 0.0 + defaultDisplayUnit: kelvin + heat_treatment_temperature_error: + type: np.float64 + unit: kelvin + description: | + Magnitude of the standard deviation of the heat_treatment_temperature. + m_annotations: + eln: + component: NumberEditQuantity + minValue: 0.0 + defaultDisplayUnit: kelvin + heat_treatment_quenching_rate: + type: np.float64 + unit: kelvin/second + description: | + Rate of the last quenching step. + m_annotations: + eln: + component: NumberEditQuantity + minValue: 0.0 + defaultDisplayUnit: kelvin/second + heat_treatment_quenching_rate_error: + type: np.float64 + unit: K/s + description: | + Magnitude of the standard deviation of the heat_treatment_quenching_rate. + m_annotations: + eln: + component: NumberEditQuantity + minValue: 0.0 + defaultDisplayUnit: K/s + specimen: + section: + description: | + Details about the specimen and its immediate environment. + m_annotations: + eln: + quantities: + name: + type: str + description: | + GUID which distinguishes the specimen from all others and especially + the predecessor/origin from where the specimen was cut. + In cases where the specimen was e.g. site-specifically cut from + samples or in cases of an instrument session during which multiple + specimens are loaded, the name has to be descriptive enough to + resolve which specimen on e.g. the microtip array was taken. + This field must not be used for an alias of the specimen. + Instead, use short_title. + m_annotations: + eln: + component: StringEditQuantity + # sample_history: + # type: str + # description: | + # Reference to the location of or a GUID providing as many details + # as possible of the material, its microstructure, and its + # thermo-chemo-mechanical processing/preparation history. + # m_annotations: + # eln: + # component: StringEditQuantity + preparation_date: + type: Datetime + description: | + ISO 8601 time code with local time zone offset to UTC + when the measured specimen surface was prepared last time. + m_annotations: + eln: + component: DateTimeEditQuantity + is_polycrystalline: + type: bool + description: | + Is the specimen, i.e. the tip, polycrystalline, i.e. does + it includes a grain or phase boundary? + m_annotations: + eln: + component: BoolEditQuantity + alias: + type: str + description: | + Possibility to give an abbreviation of the specimen name field. + m_annotations: + eln: + component: StringEditQuantity + # atom_types should be a list of strings + # atom_types: + # type: str + # shape: ['*'] + # description: | + # Use Hill's system for listing elements of the periodic table which + # are inside or attached to the surface of the specimen and thus + # relevant from a scientific point of view. + # m_annotations: + # eln: + # component: StringEditQuantity + description: + type: str + description: | + Discouraged free text field to be used in the case when properly + designed records for the sample_history are not available. + m_annotations: + eln: + component: RichTextEditQuantity user: repeats: true section: @@ -193,102 +332,6 @@ definitions: m_annotations: eln: component: StringEditQuantity - specimen: - section: - description: | - Details about the specimen and its immediate environment. - m_annotations: - eln: - quantities: - name: - type: str - description: | - GUID which distinguishes the specimen from all others and especially - the predecessor/origin from where the specimen was cut. - In cases where the specimen was e.g. site-specifically cut from - samples or in cases of an instrument session during which multiple - specimens are loaded, the name has to be descriptive enough to - resolve which specimen on e.g. the microtip array was taken. - This field must not be used for an alias of the specimen. - Instead, use short_title. - m_annotations: - eln: - component: StringEditQuantity - sample_history: - type: str - description: | - Reference to the location of or a GUID providing as many details - as possible of the material, its microstructure, and its - thermo-chemo-mechanical processing/preparation history. - m_annotations: - eln: - component: StringEditQuantity - preparation_date: - type: Datetime - description: | - ISO 8601 time code with local time zone offset to UTC information when - the measured specimen surface was actively prepared. - m_annotations: - eln: - component: DateTimeEditQuantity - short_title: - type: str - description: Possibility to give an abbreviation of the specimen name field. - m_annotations: - eln: - component: StringEditQuantity - # atom_types should be a list of strings - atom_types: - type: str - shape: ['*'] - description: | - Use Hill's system for listing elements of the periodic table which - are inside or attached to the surface of the specimen and thus - relevant from a scientific point of view. - m_annotations: - eln: - component: StringEditQuantity - description: - type: str - description: | - Discouraged free text field to be used in the case when properly - designed records for the sample_history are not available. - m_annotations: - eln: - component: StringEditQuantity - # composition_element_symbol: - # type: str - # shape: ['*'] - # description: | - # Chemical symbol. - # m_annotations: - # eln: - # component: StringEditQuantity - # composition_mass_fraction: - # type: np.float64 - # shape: ['*'] - # description: | - # Composition but this can be atomic or mass fraction. - # Best is you specify which you want. Under the hood oasis uses pint - # /nomad/nomad/units is the place where you can predefine exotic - # constants and units for a local oasis instance - # m_annotations: - # eln: - # component: NumberEditQuantity - # minValue: 0. - # maxValue: 1. - # composition_mass_fraction_error: - # type: np.float64 - # shape: ['*'] - # description: | - # Composition but this can be atomic or mass fraction. - # Also here best to be specific. If people write at.-% but mean wt.-% you - # cannot guard yourself against this - # m_annotations: - # eln: - # component: NumberEditQuantity - # minValue: 0. - # maxValue: 1. atom_probe: section: description: | @@ -302,6 +345,7 @@ definitions: type_data: - success - failure + - unknown description: | A statement whether the measurement was successful or failed prematurely. @@ -314,6 +358,14 @@ definitions: m_annotations: eln: component: StringEditQuantity + location: + type: str + description: | + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + m_annotations: + eln: + component: StringEditQuantity # (NXfabrication): flight_path_length: type: np.float64 @@ -327,6 +379,18 @@ definitions: defaultDisplayUnit: meter minValue: 0.0 maxValue: 10.0 + field_of_view: + type: np.float64 + unit: meter + description: | + The nominal diameter of the specimen ROI which is measured in the + experiment. Physically, the specimen cannot be measured completely + because ions may launch but not become detected or hit elsewhere. + m_annotations: + eln: + component: NumberEditQuantity + defaultDisplayUnit: meter + minValue: 0.0 fabrication_vendor: type: str description: Name of the manufacturer/company, i.e. AMETEK/Cameca. From b8812d1badc0144cd704dbd1fcb103bdacc4d5af Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Mon, 12 Jun 2023 10:56:04 +0200 Subject: [PATCH 05/18] Refactored loading of ELN- and deployment-specific metadata, added support for dual-laser setup of LEAP6000 instrument, initial code styling, linting round, next steps i) implement reading of composition from ELN, ii) test --- .../apm_deployment_specifics_to_nx_map.py | 11 +- .../apm/map_concepts/apm_eln_to_nx_map.py | 120 +- pynxtools/dataconverter/readers/apm/reader.py | 11 +- .../readers/apm/utils/apm_define_io_cases.py | 12 + .../utils/apm_load_deployment_specifics.py | 11 +- .../readers/apm/utils/apm_load_generic_eln.py | 416 +--- pynxtools/definitions | 2 +- pynxtools/nyaml2nxdl/NXapm.nxdl.xml | 1696 ----------------- pynxtools/nyaml2nxdl/NXapm.yaml | 1548 --------------- .../nxapm.schema.archive.yaml | 92 +- 10 files changed, 226 insertions(+), 3693 deletions(-) delete mode 100644 pynxtools/nyaml2nxdl/NXapm.nxdl.xml delete mode 100644 pynxtools/nyaml2nxdl/NXapm.yaml diff --git a/pynxtools/dataconverter/readers/apm/map_concepts/apm_deployment_specifics_to_nx_map.py b/pynxtools/dataconverter/readers/apm/map_concepts/apm_deployment_specifics_to_nx_map.py index 0a56be5d8..d4cdf84f6 100644 --- a/pynxtools/dataconverter/readers/apm/map_concepts/apm_deployment_specifics_to_nx_map.py +++ b/pynxtools/dataconverter/readers/apm/map_concepts/apm_deployment_specifics_to_nx_map.py @@ -40,12 +40,13 @@ # such that it executes after reading generic ELN data (eventually available entries) # in the template get overwritten -from pynxtools.dataconverter.readers.apm.utils \ +from pynxtools.dataconverter.readers.apm.utils.apm_versioning \ import NX_APM_ADEF_NAME, NX_APM_ADEF_VERSION, NX_APM_EXEC_NAME, NX_APM_EXEC_VERSION NxApmDeploymentSpecificInput \ - = {"ENTRY[entry*]/@version": f"{NX_APM_ADEF_VERSION}", - "ENTRY[entry*]/definition": f"{NX_APM_ADEF_NAME}", - "ENTRY[entry*]/PROGRAM[program1]/program": f"{NX_APM_EXEC_NAME}", - "ENTRY[entry*]/PROGRAM[program1]/program/@version": f"{NX_APM_EXEC_VERSION}"} + = {"/ENTRY[entry*]/@version": f"{NX_APM_ADEF_VERSION}", + "/ENTRY[entry*]/definition": f"{NX_APM_ADEF_NAME}", + "/ENTRY[entry*]/PROGRAM[program1]/program": f"{NX_APM_EXEC_NAME}", + "/ENTRY[entry*]/PROGRAM[program1]/program/@version": f"{NX_APM_EXEC_VERSION}", + "/ENTRY[entry*]/atom_probe/location": {"fun": "load_from", "terms": "location"}} diff --git a/pynxtools/dataconverter/readers/apm/map_concepts/apm_eln_to_nx_map.py b/pynxtools/dataconverter/readers/apm/map_concepts/apm_eln_to_nx_map.py index 45b569761..76c763f47 100644 --- a/pynxtools/dataconverter/readers/apm/map_concepts/apm_eln_to_nx_map.py +++ b/pynxtools/dataconverter/readers/apm/map_concepts/apm_eln_to_nx_map.py @@ -18,42 +18,79 @@ """Dict mapping custom schema instances from eln_data.yaml file on concepts in NXapm.""" NxApmElnInput = {"IGNORE": {"fun": "load_from_dict_list", "terms": "em_lab/detector"}, - "IGNORE": {"fun": "load_from", "terms": "em_lab/ebeam_column/aberration_correction/applied"}, - "IGNORE": {"fun": "load_from_dict_list", "terms": "em_lab/ebeam_column/aperture_em"}, - "/ENTRY[entry*]/em_lab/EBEAM_COLUMN[ebeam_column]/electron_source/emitter_type": {"fun": "load_from", "terms": "em_lab/ebeam_column/electron_source/emitter_type"}, - "/ENTRY[entry*]/em_lab/EBEAM_COLUMN[ebeam_column]/electron_source/voltage/@units": {"fun": "load_from", "terms": "em_lab/ebeam_column/electron_source/voltage/unit"}, - "/ENTRY[entry*]/em_lab/EBEAM_COLUMN[ebeam_column]/electron_source/voltage": {"fun": "load_from", "terms": "em_lab/ebeam_column/electron_source/voltage/value"}, - "/ENTRY[entry*]/em_lab/FABRICATION[fabrication]/capabilities": {"fun": "load_from", "terms": "em_lab/fabrication/capabilities"}, - "/ENTRY[entry*]/em_lab/FABRICATION[fabrication]/identifier": {"fun": "load_from", "terms": "em_lab/fabrication/identifier"}, - "/ENTRY[entry*]/em_lab/FABRICATION[fabrication]/model": {"fun": "load_from", "terms": "em_lab/fabrication/model"}, - "/ENTRY[entry*]/em_lab/FABRICATION[fabrication]/vendor": {"fun": "load_from", "terms": "em_lab/fabrication/vendor"}, - "/ENTRY[entry*]/em_lab/instrument_name": {"fun": "load_from", "terms": "em_lab/instrument_name"}, - "/ENTRY[entry*]/em_lab/location": {"fun": "load_from", "terms": "em_lab/location"}, - "IGNORE": {"fun": "load_from", "terms": "em_lab/optical_system_em/beam_current/unit"}, - "IGNORE": {"fun": "load_from", "terms": "em_lab/optical_system_em/beam_current/value"}, - "IGNORE": {"fun": "load_from", "terms": "em_lab/optical_system_em/beam_current_description"}, - "IGNORE": {"fun": "load_from", "terms": "em_lab/optical_system_em/magnification"}, - "IGNORE": {"fun": "load_from", "terms": "em_lab/optical_system_em/semi_convergence_angle/unit"}, - "IGNORE": {"fun": "load_from", "terms": "em_lab/optical_system_em/semi_convergence_angle/value"}, - "/ENTRY[entry*]/em_lab/stage_lab/description": {"fun": "load_from", "terms": "em_lab/stage_lab/description"}, - "/ENTRY[entry*]/em_lab/stage_lab/name": {"fun": "load_from", "terms": "em_lab/stage_lab/name"}, - "/ENTRY[entry*]/@version": {"fun": "load_from", "terms": "entry/attr_version"}, - "/ENTRY[entry*]/definition": {"fun": "load_from", "terms": "entry/definition"}, - "/ENTRY[entry*]/end_time": {"fun": "load_from", "terms": "entry/end_time"}, - "/ENTRY[entry*]/experiment_description": {"fun": "load_from", "terms": "entry/experiment_description"}, - "/ENTRY[entry*]/experiment_identifier": {"fun": "load_from", "terms": "entry/experiment_identifier"}, - "/ENTRY[entry*]/PROGRAM[program*]/program": {"fun": "load_from", "terms": "entry/program"}, - "/ENTRY[entry*]/PROGRAM[program*]/program/@version": {"fun": "load_from", "terms": "entry/program__attr_version"}, - "/ENTRY[entry*]/start_time": {"fun": "load_from", "terms": "entry/start_time"}, - "IGNORE": {"fun": "load_from_list_of_dict", "terms": "user"}} + "IGNORE": {"fun": "load_from", "terms": "em_lab/ebeam_column/aberration_correction/applied"}, + "IGNORE": {"fun": "load_from_dict_list", "terms": "em_lab/ebeam_column/aperture_em"}, + "/ENTRY[entry*]/PROGRAM[program2]/program": {"fun": "load_from", "terms": "atom_probe/control_software_program"}, + "/ENTRY[entry*]/PROGRAM[program2]/program/@version": {"fun": "load_from", "terms": "atom_probe/control_software_program__attr_version"}, + "/ENTRY[entry*]/experiment_identifier": {"fun": "load_from", "terms": "entry/experiment_identifier"}, + "/ENTRY[entry*]/start_time": {"fun": "load_from", "terms": "entry/start_time"}, + "/ENTRY[entry*]/end_time": {"fun": "load_from", "terms": "entry/end_time"}, + "/ENTRY[entry*]/run_number": {"fun": "load_from", "terms": "entry/run_number"}, + "/ENTRY[entry*]/operation_mode": {"fun": "load_from", "terms": "entry/operation_mode"}, + "/ENTRY[entry*]/experiment_description": {"fun": "load_from", "terms": "entry/experiment_description"}, + "IGNORE": {"fun": "load_from", "terms": "sample/alias"}, + "/ENTRY[entry*]/sample/grain_diameter": {"fun": "load_from", "terms": "sample/grain_diameter/value"}, + "/ENTRY[entry*]/sample/grain_diameter/@units": {"fun": "load_from", "terms": "sample/grain_diameter/unit"}, + "/ENTRY[entry*]/sample/grain_diameter_error": {"fun": "load_from", "terms": "sample/grain_diameter_error/value"}, + "/ENTRY[entry*]/sample/grain_diameter_error/@units": {"fun": "load_from", "terms": "sample/grain_diameter_error/unit"}, + "/ENTRY[entry*]/sample/heat_treatment_quenching_rate": {"fun": "load_from", "terms": "sample/heat_treatment_quenching_rate/value"}, + "/ENTRY[entry*]/sample/heat_treatment_quenching_rate/@units": {"fun": "load_from", "terms": "sample/heat_treatment_quenching_rate/unit"}, + "/ENTRY[entry*]/sample/heat_treatment_quenching_rate_error": {"fun": "load_from", "terms": "sample/heat_treatment_quenching_rate_error/value"}, + "/ENTRY[entry*]/sample/heat_treatment_quenching_rate_error/@units": {"fun": "load_from", "terms": "sample/heat_treatment_quenching_rate_error/unit"}, + "/ENTRY[entry*]/sample/heat_treatment_temperature": {"fun": "load_from", "terms": "sample/heat_treatment_temperature/value"}, + "/ENTRY[entry*]/sample/heat_treatment_temperature/@units": {"fun": "load_from", "terms": "sample/heat_treatment_temperature/unit"}, + "/ENTRY[entry*]/sample/heat_treatment_temperature_error": {"fun": "load_from", "terms": "sample/heat_treatment_temperature_error/value"}, + "/ENTRY[entry*]/sample/heat_treatment_temperature_error/@units": {"fun": "load_from", "terms": "sample/heat_treatment_temperature_error/unit"}, + "/ENTRY[entry*]/specimen/name": {"fun": "load_from", "terms": "specimen/name"}, + "/ENTRY[entry*]/specimen/preparation_date": {"fun": "load_from", "terms": "specimen/preparation_date"}, + "IGNORE": {"fun": "load_from", "terms": "specimen/sample_history"}, + "/ENTRY[entry*]/specimen/alias": {"fun": "load_from", "terms": "specimen/alias"}, + "/ENTRY[entry*]/specimen/is_polycrystalline": {"fun": "load_from", "terms": "specimen/is_polycrystalline"}, + "/ENTRY[entry*]/specimen/description": {"fun": "load_from", "terms": "specimen/description"}, + "/ENTRY[entry*]/atom_probe/FABRICATION[fabrication]/identifier": {"fun": "load_from", "terms": "atom_probe/fabrication_identifier"}, + "/ENTRY[entry*]/atom_probe/FABRICATION[fabrication]/model": {"fun": "load_from", "terms": "atom_probe/fabrication_model"}, + "/ENTRY[entry*]/atom_probe/FABRICATION[fabrication]/vendor": {"fun": "load_from", "terms": "atom_probe/fabrication_vendor"}, + "/ENTRY[entry*]/atom_probe/analysis_chamber/pressure": {"fun": "load_from", "terms": "atom_probe/analysis_chamber_pressure/value"}, + "/ENTRY[entry*]/atom_probe/analysis_chamber/pressure/@units": {"fun": "load_from", "terms": "atom_probe/analysis_chamber_pressure/unit"}, + "/ENTRY[entry*]/atom_probe/control_software/PROGRAM[program1]/program": {"fun": "load_from", "terms": "atom_probe/control_software_program"}, + "/ENTRY[entry*]/atom_probe/control_software/PROGRAM[program1]/program/@version": {"fun": "load_from", "terms": "atom_probe/control_software_program__attr_version"}, + "/ENTRY[entry*]/atom_probe/field_of_view": {"fun": "load_from", "terms": "atom_probe/field_of_view/value"}, + "/ENTRY[entry*]/atom_probe/field_of_view/@units": {"fun": "load_from", "terms": "atom_probe/field_of_view/unit"}, + "/ENTRY[entry*]/atom_probe/flight_path_length": {"fun": "load_from", "terms": "atom_probe/flight_path_length/value"}, + "/ENTRY[entry*]/atom_probe/flight_path_length/@units": {"fun": "load_from", "terms": "atom_probe/flight_path_length/unit"}, + "/ENTRY[entry*]/atom_probe/instrument_name": {"fun": "load_from", "terms": "atom_probe/instrument_name"}, + "/ENTRY[entry*]/atom_probe/ion_detector/model": {"fun": "load_from", "terms": "atom_probe/ion_detector_model"}, + "/ENTRY[entry*]/atom_probe/ion_detector/name": {"fun": "load_from", "terms": "atom_probe/ion_detector_name"}, + "/ENTRY[entry*]/atom_probe/ion_detector/serial_number": {"fun": "load_from", "terms": "atom_probe/ion_detector_serial_number"}, + "/ENTRY[entry*]/atom_probe/ion_detector/type": {"fun": "load_from", "terms": "atom_probe/ion_detector_type"}, + "/ENTRY[entry*]/atom_probe/local_electrode/name": {"fun": "load_from", "terms": "atom_probe/local_electrode_name"}, + "/ENTRY[entry*]/atom_probe/location": {"fun": "load_from", "terms": "atom_probe/location"}, + "/ENTRY[entry*]/atom_probe/REFLECTRON[reflectron]/applied": {"fun": "load_from", "terms": "atom_probe/reflectron_applied"}, + "/ENTRY[entry*]/atom_probe/stage_lab/base_temperature": {"fun": "load_from", "terms": "atom_probe/stage_lab_base_temperature/value"}, + "/ENTRY[entry*]/atom_probe/stage_lab/base_temperature/@units": {"fun": "load_from", "terms": "atom_probe/stage_lab_base_temperature/unit"}, + "/ENTRY[entry*]/atom_probe/specimen_monitoring/detection_rate": {"fun": "load_from", "terms": "atom_probe/specimen_monitoring_detection_rate/value"}, + "/ENTRY[entry*]/atom_probe/specimen_monitoring/detection_rate/@units": {"fun": "load_from", "terms": "atom_probe/specimen_monitoring_detection_rate/unit"}, + "/ENTRY[entry*]/atom_probe/specimen_monitoring/initial_radius": {"fun": "load_from", "terms": "atom_probe/specimen_monitoring_initial_radius/value"}, + "/ENTRY[entry*]/atom_probe/specimen_monitoring/initial_radius/@units": {"fun": "load_from", "terms": "atom_probe/specimen_monitoring_initial_radius/unit"}, + "/ENTRY[entry*]/atom_probe/specimen_monitoring/shank_angle": {"fun": "load_from", "terms": "atom_probe/specimen_monitoring_shank_angle/value"}, + "/ENTRY[entry*]/atom_probe/specimen_monitoring/shank_angle/@units": {"fun": "load_from", "terms": "atom_probe/specimen_monitoring_shank_angle/unit"}, + "/ENTRY[entry*]/atom_probe/status": {"fun": "load_from", "terms": "atom_probe/status"}, + "/ENTRY[entry*]/atom_probe/pulser/pulse_fraction": {"fun": "load_from", "terms": "atom_probe/pulser/pulse_fraction"}, + "/ENTRY[entry*]/atom_probe/pulser/pulse_frequency": {"fun": "load_from", "terms": "atom_probe/pulser/pulse_frequency/value"}, + "/ENTRY[entry*]/atom_probe/pulser/pulse_frequency/@units": {"fun": "load_from", "terms": "atom_probe/pulser/pulse_frequency/unit"}, + "/ENTRY[entry*]/atom_probe/pulser/pulse_mode": {"fun": "load_from", "terms": "atom_probe/pulser/pulse_mode"}, + "/ENTRY[entry*]/atom_probe/ranging/PROGRAM[program1]/program": {"fun": "load_from", "terms": "atom_probe/ranging/program"}, + "/ENTRY[entry*]/atom_probe/ranging/PROGRAM[program1]/program/@version": {"fun": "load_from", "terms": "atom_probe/ranging/program__attr_version"}, + "/ENTRY[entry*]/atom_probe/reconstruction/PROGRAM[program1]/program": {"fun": "load_from", "terms": "atom_probe/reconstruction/program"}, + "/ENTRY[entry*]/atom_probe/reconstruction/PROGRAM[program1]/program/@version": {"fun": "load_from", "terms": "atom_probe/reconstruction/program__attr_version"}, + "/ENTRY[entry*]/atom_probe/reconstruction/crystallographic_calibration": {"fun": "load_from", "terms": "atom_probe/reconstruction/crystallographic_calibration"}, + "/ENTRY[entry*]/atom_probe/reconstruction/parameter": {"fun": "load_from", "terms": "atom_probe/reconstruction/parameter"}, + "/ENTRY[entry*]/atom_probe/reconstruction/protocol_name": {"fun": "load_from", "terms": "atom_probe/reconstruction/protocol_name"}} # NeXus concept specific mapping tables which require special treatment as the current # NOMAD OASIS custom schema implementation delivers them as a list of dictionaries instead # of a directly flattenable list of keyword, value pairs -NxApertureEmFromListOfDict = {"/ENTRY[entry*]/em_lab/EBEAM_COLUMN[ebeam_column]/APERTURE_EM[aperture_em*]/name": {"fun": "load_from", "terms": "name"}, - "/ENTRY[entry*]/em_lab/EBEAM_COLUMN[ebeam_column]/APERTURE_EM[aperture_em*]/value": {"fun": "load_from", "terms": "value"}} - NxUserFromListOfDict = {"/ENTRY[entry*]/USER[user*]/name": {"fun": "load_from", "terms": "name"}, "/ENTRY[entry*]/USER[user*]/affiliation": {"fun": "load_from", "terms": "affiliation"}, "/ENTRY[entry*]/USER[user*]/address": {"fun": "load_from", "terms": "address"}, @@ -65,19 +102,8 @@ "/ENTRY[entry*]/USER[user*]/social_media_name": {"fun": "load_from", "terms": "social_media_name"}, "/ENTRY[entry*]/USER[user*]/social_media_platform": {"fun": "load_from", "terms": "social_media_platform"}} -NxDetectorListOfDict = {"/ENTRY[entry*]/em_lab/DETECTOR[detector*]/local_name": {"fun": "load_from", "terms": "local_name"}} - -# atom_types is a good example for specific cases where one cannot just blindly map -# the list that comes from the custom schema ELN instance, because -# people may enter invalid types of atoms (which would generate problems in NOMAD OASIS) -# and for NeXus we would like to have a "string of a comma-separated list of element names" - -NxSample = {"IGNORE": {"fun": "load_from", "terms": "sample/atom_types"}, - "/ENTRY[entry*]/sample/description": {"fun": "load_from", "terms": "sample/description"}, - "/ENTRY[entry*]/sample/method": {"fun": "load_from", "terms": "sample/method"}, - "/ENTRY[entry*]/sample/name": {"fun": "load_from", "terms": "sample/name"}, - "/ENTRY[entry*]/sample/preparation_date": {"fun": "load_from", "terms": "sample/preparation_date"}, - "/ENTRY[entry*]/sample/sample_history": {"fun": "load_from", "terms": "sample/sample_history"}, - "/ENTRY[entry*]/sample/short_title": {"fun": "load_from", "terms": "sample/short_title"}, - "/ENTRY[entry*]/sample/thickness": {"fun": "load_from", "terms": "sample/thickness/value"}, - "/ENTRY[entry*]/sample/thickness/@units": {"fun": "load_from", "terms": "sample/thickness/unit"}} +# LEAP6000 can use up to two lasers and voltage pulsing (both at the same time?) +NxPulserFromListOfDict = {"/ENTRY[entry*]/atom_probe/pulser/SOURCE[source*]/name": {"fun": "load_from", "terms": "name"}, + "/ENTRY[entry*]/atom_probe/pulser/SOURCE[source*]/power": {"fun": "load_from", "terms": "power"}, + "/ENTRY[entry*]/atom_probe/pulser/SOURCE[source*]/pulse_energy": {"fun": "load_from", "terms": "pulse_energy"}, + "/ENTRY[entry*]/atom_probe/pulser/SOURCE[source*]/wavelength": {"fun": "load_from", "terms": "wavelength"}} diff --git a/pynxtools/dataconverter/readers/apm/reader.py b/pynxtools/dataconverter/readers/apm/reader.py index 729945c6b..4ab082496 100644 --- a/pynxtools/dataconverter/readers/apm/reader.py +++ b/pynxtools/dataconverter/readers/apm/reader.py @@ -129,13 +129,10 @@ def read(self, print("Create NeXus default plottable data...") apm_default_plot_generator(template, n_entries) - debugging = False - if debugging is True: - print("Reporting state of template before passing to HDF5 writing...") - for keyword in template.keys(): - print(keyword) - # print(type(template[keyword])) - # print(template[keyword]) + print("Reporting state of template before passing to HDF5 writing...") + for keyword in template.keys(): + print(keyword) + # print(template[keyword]) print("Forward instantiated template to the NXS writer...") return template diff --git a/pynxtools/dataconverter/readers/apm/utils/apm_define_io_cases.py b/pynxtools/dataconverter/readers/apm/utils/apm_define_io_cases.py index 6b02f3283..26a73a1e9 100644 --- a/pynxtools/dataconverter/readers/apm/utils/apm_define_io_cases.py +++ b/pynxtools/dataconverter/readers/apm/utils/apm_define_io_cases.py @@ -36,11 +36,21 @@ def __init__(self, file_paths: Tuple[str] = None): eln injects additional metadata and eventually numerical data. """ self.case: Dict[str, list] = {} + self.eln: List[str] = [] + self.cfg: List[str] = [] + self.reconstruction: List[str] = [] + self.ranging: List[str] = [] self.is_valid = False self.supported_mime_types = [ "pos", "epos", "apt", "rrng", "rng", "txt", "yaml", "yml"] for mime_type in self.supported_mime_types: self.case[mime_type] = [] + + self.sort_files_by_mime_type(file_paths) + self.check_validity_of_file_combinations() + + def sort_files_by_mime_type(self, file_paths: Tuple[str] = None): + """Sort all input-files based on their mimetype to prepare validity check.""" for file_name in file_paths: index = file_name.lower().rfind(".") if index >= 0: @@ -49,6 +59,8 @@ def __init__(self, file_paths: Tuple[str] = None): if file_name not in self.case[suffix]: self.case[suffix].append(file_name) + def check_validity_of_file_combinations(self): + """Check if this combination of types of files is supported.""" recon_input = 0 # reconstruction relevant file e.g. POS, ePOS, APT range_input = 0 # ranging definition file, e.g. RNG, RRNG other_input = 0 # generic ELN or OASIS-specific configurations diff --git a/pynxtools/dataconverter/readers/apm/utils/apm_load_deployment_specifics.py b/pynxtools/dataconverter/readers/apm/utils/apm_load_deployment_specifics.py index 309f31c7e..87dc05950 100644 --- a/pynxtools/dataconverter/readers/apm/utils/apm_load_deployment_specifics.py +++ b/pynxtools/dataconverter/readers/apm/utils/apm_load_deployment_specifics.py @@ -15,14 +15,12 @@ # See the License for the specific language governing permissions and # limitations under the License. # -"""Load deployment specific quantities.""" +"""Load deployment-specific quantities.""" # pylint: disable=no-member import flatdict as fd -import numpy as np - import yaml from pynxtools.dataconverter.readers.apm.map_concepts.apm_deployment_specifics_to_nx_map \ @@ -48,13 +46,12 @@ def __init__(self, file_name: str, entry_id: int): self.file_name = "" self.yml = {} - def parse_other_sections(self, template: dict) -> dict: + def report(self, template: dict) -> dict: """Copy data from configuration applying mapping functors.""" for nx_path, modifier in NxApmDeploymentSpecificInput.items(): - if (nx_path != "IGNORE") and (nx_path != "UNCLEAR"): + if nx_path not in ("IGNORE", "UNCLEAR"): trg = variadic_path_to_specific_path(nx_path, [self.entry_id, 1]) res = apply_modifier(modifier, self.yml) if res is not None: template[trg] = res - - return template \ No newline at end of file + return template diff --git a/pynxtools/dataconverter/readers/apm/utils/apm_load_generic_eln.py b/pynxtools/dataconverter/readers/apm/utils/apm_load_generic_eln.py index 41677a1eb..2cdf8794a 100644 --- a/pynxtools/dataconverter/readers/apm/utils/apm_load_generic_eln.py +++ b/pynxtools/dataconverter/readers/apm/utils/apm_load_generic_eln.py @@ -17,18 +17,19 @@ # """Wrapping multiple parsers for vendor files with NOMAD OASIS/ELN/YAML metadata.""" -# pylint: disable=no-member +# pylint: disable=no-member,duplicate-code,too-many-nested-blocks import flatdict as fd -import numpy as np - import yaml -from ase.data import chemical_symbols +# from ase.data import chemical_symbols + +from pynxtools.dataconverter.readers.apm.map_concepts.apm_eln_to_nx_map \ + import NxApmElnInput, NxUserFromListOfDict -from pynxtools.dataconverter.readers.apm.utils.apm_versioning \ - import NX_APM_ADEF_NAME, NX_APM_ADEF_VERSION, NX_APM_EXEC_NAME, NX_APM_EXEC_VERSION +from pynxtools.dataconverter.readers.shared.map_concepts.mapping_functors \ + import variadic_path_to_specific_path, apply_modifier class NxApmNomadOasisElnSchemaParser: # pylint: disable=too-few-public-methods @@ -56,354 +57,85 @@ def __init__(self, file_name: str, entry_id: int): self.entry_id = entry_id self.file_name = file_name with open(self.file_name, "r", encoding="utf-8") as stream: - self.yml = fd.FlatDict(yaml.safe_load(stream), delimiter=":") + self.yml = fd.FlatDict(yaml.safe_load(stream), delimiter="/") else: self.entry_id = 1 self.file_name = "" self.yml = {} - def parse_entry(self, template: dict) -> dict: - """Copy data in entry section.""" - # print("Parsing entry...") - trg = f"/ENTRY[entry{self.entry_id}]/" - src = "entry" - if isinstance(self.yml[src], fd.FlatDict): - if (self.yml[f"{src}:attr_version"] == NX_APM_ADEF_VERSION) \ - and (self.yml[f"{src}:definition"] == NX_APM_ADEF_NAME): - template[f"{trg}@version"] = NX_APM_ADEF_VERSION - template[f"{trg}definition"] = NX_APM_ADEF_NAME - template[f"{trg}PROGRAM[program1]/program"] = NX_APM_EXEC_NAME - template[f"{trg}PROGRAM[program1]/program/@version"] = NX_APM_EXEC_VERSION - if ("program" in self.yml[src].keys()) \ - and ("program__attr_version" in self.yml[src].keys()): - template[f"{trg}PROGRAM[program2]/program"] \ - = self.yml[f"{src}:program"] - template[f"{trg}PROGRAM[program2]/program/@version"] \ - = self.yml[f"{src}:program__attr_version"] - - required_field_names = ["experiment_identifier", "run_number", - "operation_mode"] - for field_name in required_field_names: - if field_name in self.yml[src].keys(): - template[f"{trg}{field_name}"] = self.yml[f"{src}:{field_name}"] - - optional_field_names = ["start_time", "end_time", - "experiment_description", "experiment_documentation"] - for field_name in optional_field_names: - if field_name in self.yml[src].keys(): - template[f"{trg}{field_name}"] = self.yml[f"{src}:{field_name}"] - + def parse_sample_composition(self, template: dict) -> dict: + """Interpret human-readable ELN input to generate consistent composition table.""" return template - def parse_user(self, template: dict) -> dict: - """Copy data in user section.""" - # print("Parsing user...") + def parse_user_section(self, template: dict) -> dict: + """Copy data from user section into template.""" src = "user" - if "user" in self.yml.keys(): - if len(self.yml[src]) >= 1: - user_id = 1 - for user_list in self.yml[src]: - trg = f"/ENTRY[entry{self.entry_id}]/USER[user{user_id}]/" - - required_field_names = ["name"] - for field_name in required_field_names: - if field_name in user_list.keys(): - template[f"{trg}{field_name}"] = user_list[field_name] - - optional_field_names = ["email", "affiliation", "address", - "orcid", "orcid_platform", - "telephone_number", "role", - "social_media_name", "social_media_platform"] - for field_name in optional_field_names: - if field_name in user_list.keys(): - template[f"{trg}{field_name}"] = user_list[field_name] - user_id += 1 - - return template - - def parse_specimen(self, template: dict) -> dict: - """Copy data in specimen section.""" - # print("Parsing sample...") - src = "specimen" - trg = f"/ENTRY[entry{self.entry_id}]/specimen/" - if isinstance(self.yml[src], fd.FlatDict): - if (isinstance(self.yml[f"{src}:atom_types"], list)) \ - and (len(self.yml[src + ":atom_types"]) >= 1): - atom_types_are_valid = True - for symbol in self.yml[f"{src}:atom_types"]: - valid = isinstance(symbol, str) \ - and (symbol in chemical_symbols) and (symbol != "X") - if valid is False: - atom_types_are_valid = False - break - if atom_types_are_valid is True: - template[f"{trg}atom_types"] \ - = ", ".join(list(self.yml[f"{src}:atom_types"])) - - required_field_names = ["name", "sample_history", "preparation_date"] - for field_name in required_field_names: - if field_name in self.yml[src].keys(): - template[f"{trg}{field_name}"] = self.yml[f"{src}:{field_name}"] - - optional_field_names = ["short_title", "description"] - for field_name in optional_field_names: - if field_name in self.yml[src].keys(): - template[f"{trg}{field_name}"] = self.yml[f"{src}:{field_name}"] - - return template - - def parse_instrument_header(self, template: dict) -> dict: - """Copy data in instrument_header section.""" - # print("Parsing instrument header...") - src = "atom_probe" - trg = f"/ENTRY[entry{self.entry_id}]/atom_probe/" - if isinstance(self.yml[src], fd.FlatDict): - required_field_names = ["instrument_name", "status"] - for field_name in required_field_names: - if field_name in self.yml[src].keys(): - template[f"{trg}{field_name}"] = self.yml[f"{src}:{field_name}"] - optional_field_names = ["location"] - for field_name in optional_field_names: - if field_name in self.yml[src].keys(): - template[f"{trg}{field_name}"] = self.yml[f"{src}:{field_name}"] - - float_field_names = ["flight_path_length", "field_of_view"] - for field_name in float_field_names: - if (f"{field_name}:value" in self.yml[src].keys()) \ - and (f"{field_name}:unit" in self.yml[src].keys()): - template[f"{trg}{field_name}"] \ - = np.float64(self.yml[f"{src}:{field_name}:value"]) - template[f"{trg}{field_name}/@units"] \ - = self.yml[f"{src}:{field_name}:unit"] - - return template - - def parse_fabrication(self, template: dict) -> dict: - """Copy data in fabrication section.""" - # print("Parsing fabrication...") - src = "atom_probe" - trg = f"/ENTRY[entry{self.entry_id}]/atom_probe/FABRICATION[fabrication]/" - required_field_names = ["fabrication_vendor", "fabrication_model"] - for field_name in required_field_names: - if field_name in self.yml[src].keys(): - suffix = field_name.replace("fabrication_", "") - template[f"{trg}{suffix}"] = self.yml[f"{src}:{field_name}"] - - optional_field_names = ["fabrication_identifier", "fabrication_capabilities"] - for field_name in optional_field_names: - if field_name in self.yml[src].keys(): - suffix = field_name.replace("fabrication_", "") - template[f"{trg}{suffix}"] = self.yml[f"{src}:{field_name}"] - - return template - - def parse_analysis_chamber(self, template: dict) -> dict: - """Copy data in analysis_chamber section.""" - # print("Parsing analysis chamber...") - src = "atom_probe" - trg = f"/ENTRY[entry{self.entry_id}]/atom_probe/analysis_chamber/" - float_field_names = ["analysis_chamber_pressure"] - for field_name in float_field_names: - if (f"{field_name}:value" in self.yml[src].keys()) \ - and (f"{field_name}:unit" in self.yml[src].keys()): - suffix = field_name.replace("analysis_chamber_", "") - template[f"{trg}{suffix}"] \ - = np.float64(self.yml[f"{src}:{field_name}:value"]) - template[f"{trg}{suffix}/@units"] = self.yml[f"{src}:{field_name}:unit"] - - return template - - def parse_reflectron(self, template: dict) -> dict: - """Copy data in reflectron section.""" - # print("Parsing reflectron...") - src = "atom_probe" - trg = f"/ENTRY[entry{self.entry_id}]/atom_probe/REFLECTRON[reflectron]/" - required_field_names = ["reflectron_applied"] - for field_name in required_field_names: - if field_name in self.yml[src].keys(): - suffix = field_name.replace("reflectron_", "") - template[f"{trg}{suffix}"] = self.yml[f"{src}:{field_name}"] - - return template - - def parse_local_electrode(self, template: dict) -> dict: - """Copy data in local_electrode section.""" - # print("Parsing local electrode...") - src = "atom_probe" - trg = f"/ENTRY[entry{self.entry_id}]/atom_probe/local_electrode/" - required_field_names = ["local_electrode_name"] - for field_name in required_field_names: - if field_name in self.yml[src].keys(): - suffix = field_name.replace("local_electrode_", "") - template[f"{trg}{suffix}"] = self.yml[f"{src}:{field_name}"] - - return template - - def parse_detector(self, template: dict) -> dict: - """Copy data in ion_detector section.""" - # print("Parsing detector...") - src = "atom_probe" - trg = f"/ENTRY[entry{self.entry_id}]/atom_probe/ion_detector/" - required_field_names = ["ion_detector_type", "ion_detector_name", - "ion_detector_model", "ion_detector_serial_number"] - for field_name in required_field_names: - if field_name in self.yml[src].keys(): - suffix = field_name.replace("ion_detector_", "") - template[f"{trg}{suffix}"] = self.yml[f"{src}:{field_name}"] - - return template - - def parse_stage_lab(self, template: dict) -> dict: - """Copy data in stage lab section.""" - # print("Parsing stage_lab...") - src = "atom_probe" - trg = f"/ENTRY[entry{self.entry_id}]/atom_probe/stage_lab/" - if isinstance(self.yml[src], fd.FlatDict): - required_value_fields = ["stage_lab_base_temperature"] - for field_name in required_value_fields: - if (f"{field_name}:value" in self.yml[src].keys()) \ - and (f"{field_name}:unit" in self.yml[src].keys()): - suffix = field_name.replace("stage_lab_", "") - template[f"{trg}{suffix}"] \ - = np.float64(self.yml[f"{src}:{field_name}:value"]) - template[f"{trg}{suffix}/@units"] \ - = self.yml[f"{src}:{field_name}:unit"] - - return template - - def parse_specimen_monitoring(self, template: dict) -> dict: - """Copy data in specimen_monitoring section.""" - # print("Parsing specimen_monitoring...") - src = "atom_probe" - trg = f"/ENTRY[entry{self.entry_id}]/atom_probe/specimen_monitoring/" - if isinstance(self.yml[src], fd.FlatDict): - required_field_names = ["specimen_monitoring_detection_rate"] - for field_name in required_field_names: - if field_name in self.yml[src].keys(): - template[f"{trg}detection_rate"] \ - = np.float64(self.yml[f"{src}:{field_name}"]) - float_field_names = ["specimen_monitoring_initial_radius", - "specimen_monitoring_shank_angle"] - for float_field_name in float_field_names: - if (f"{float_field_name}:value" in self.yml[src].keys()) \ - and (f"{float_field_name}:unit" in self.yml[src].keys()): - suffix = float_field_name.replace("specimen_monitoring_", "") - template[f"{trg}{suffix}"] \ - = np.float64(self.yml[f"{src}:{float_field_name}:value"]) - template[f"{trg}{suffix}/@units"] \ - = self.yml[f"{src}:{float_field_name}:unit"] - - return template - - def parse_control_software(self, template: dict) -> dict: - """Copy data in control software section.""" - # print("Parsing control software...") - src = "atom_probe" - trg = f"/ENTRY[entry{self.entry_id}]/atom_probe/control_software/" - if isinstance(self.yml[src], fd.FlatDict): - prefix = "control_software" - if (f"{prefix}_program" in self.yml[src].keys()) \ - and (f"{prefix}_program__attr_version" in self.yml[src].keys()): - template[f"{trg}PROGRAM[program1]/program"] \ - = self.yml[f"{src}:{prefix}_program"] - template[f"{trg}PROGRAM[program1]/program/@version"] \ - = self.yml[f"{src}:{prefix}_program__attr_version"] - - return template - - def parse_pulser(self, template: dict) -> dict: + if src in self.yml.keys(): + if isinstance(self.yml[src], list): + if all(isinstance(entry, dict) for entry in self.yml[src]) is True: + user_id = 1 + # custom schema delivers a list of dictionaries... + for user_dict in self.yml[src]: + # ... for each of them inspect for fields mappable on NeXus + identifier = [self.entry_id, user_id] + # identifier to get instance NeXus path from variadic NeXus path + # try to find all quantities on the left-hand side of the mapping + # table and check if we can find these + for nx_path, modifier in NxUserFromListOfDict.items(): + if nx_path not in ("IGNORE", "UNCLEAR"): + trg = variadic_path_to_specific_path(nx_path, identifier) + res = apply_modifier(modifier, user_dict) + if res is not None: + template[trg] = res + user_id += 1 + return template + + def parse_laser_pulser_details(self, template: dict) -> dict: """Copy data in pulser section.""" - # print("Parsing pulser...") - src = "atom_probe:pulser" - trg = f"/ENTRY[entry{self.entry_id}]/atom_probe/pulser/" - if isinstance(self.yml[src], fd.FlatDict): - if "pulse_mode" in self.yml[src].keys(): - pulse_mode = self.yml[f"{src}:pulse_mode"] - template[f"{trg}pulse_mode"] = pulse_mode - else: # can not parse selectively as pulse_mode was not documented + # additional laser-specific details only relevant when the laser was used + src = "atom_probe/pulser/pulse_mode" + if src in self.yml.keys(): + if self.yml[src] == "voltage": return template - - if "pulse_fraction" in self.yml[src].keys(): - template[f"{trg}pulse_fraction"] \ - = np.float64(self.yml[f"{src}:pulse_fraction"]) - - float_field_names = ["pulse_frequency"] - for field_name in float_field_names: - if (f"{field_name}:value" in self.yml[src].keys()) \ - and (f"{field_name}:unit" in self.yml[src].keys()): - template[f"{trg}{field_name}"] \ - = np.float64(self.yml[f"{src}:{field_name}:value"]) - template[f"{trg}{field_name}/@units"] \ - = self.yml[f"{src}:{field_name}:unit"] - # additionally required data for laser and laser_and_voltage runs - if pulse_mode != "voltage": - trg = f"/ENTRY[entry{self.entry_id}]/atom_probe/" \ - f"pulser/SOURCE[laser_source1]/" - if "laser_source_name" in self.yml[src].keys(): - template[f"{trg}name"] = self.yml[f"{src}:laser_source_name"] - - float_field_names = ["laser_source_wavelength", - "laser_source_power", - "laser_source_pulse_energy"] - for field_name in float_field_names: - if (f"{field_name}:value" in self.yml[src].keys()) \ - and (f"{field_name}:unit" in self.yml[src].keys()): - suffix = field_name.replace("laser_source_", "") - template[f"{trg}{suffix}"] \ - = np.float64(self.yml[f"{src}:{field_name}:value"]) - template[f"{trg}{suffix}/@units"] \ - = self.yml[f"{src}:{field_name}:unit"] - - return template - - def parse_reconstruction(self, template: dict) -> dict: - """Copy data in reconstruction section.""" - # print("Parsing reconstruction...") - src = "reconstruction" - trg = f"/ENTRY[entry{self.entry_id}]/atom_probe/reconstruction/" - if ("program" in self.yml[src].keys()) \ - and ("program__attr_version" in self.yml[src].keys()): - template[f"{trg}PROGRAM[program1]/program"] \ - = self.yml[f"{src}:program"] - template[f"{trg}PROGRAM[program1]/program/@version"] \ - = self.yml[f"{src}:program__attr_version"] - - required_field_names = ["protocol_name", "parameter", - "crystallographic_calibration"] - for field_name in required_field_names: - if field_name in self.yml[src].keys(): - template[f"{trg}{field_name}"] = self.yml[f"{src}:{field_name}"] - - return template - - def parse_ranging(self, template: dict) -> dict: - """Copy data in ranging section.""" - # print("Parsing ranging...") - src = "ranging" - trg = f"/ENTRY[entry{self.entry_id}]/atom_probe/ranging/" - if ("program" in self.yml[src].keys()) \ - and ("program__attr_version" in self.yml[src].keys()): - template[f"{trg}PROGRAM[program1]/program"] = self.yml[f"{src}:program"] - template[f"{trg}PROGRAM[program1]/program/@version"] \ - = self.yml[f"{src}:program__attr_version"] - + else: + return template + src = "atom_probe/pulser/laser_source" + if src in self.yml.keys(): + if isinstance(self.yml[src], list): + if all(isinstance(entry, dict) for entry in self.yml[src]) is True: + laser_id = 1 + # custom schema delivers a list of dictionaries... + trg = f"/ENTRY[entry{self.entry_id}]/atom_probe/pulser" \ + f"/SOURCE[source{laser_id}]" + for laser_dict in self.yml[src]: + if "name" in laser_dict.keys(): + template[f"{trg}/name"] = laser_dict["name"] + quantities = ["power", "pulse_energy", "wavelength"] + for quant in quantities: + if isinstance(laser_dict[quant], dict): + if ("value" in laser_dict[quant].keys()) \ + and ("unit" in laser_dict[quant].keys()): + template[f"{trg}/{quant}"] \ + = laser_dict[quant]["value"] + template[f"{trg}/{quant}/@units"] \ + = laser_dict[quant]["unit"] + laser_id += 1 + return template + + def parse_other_sections(self, template: dict) -> dict: + """Copy data from custom schema into template.""" + for nx_path, modifier in NxApmElnInput.items(): + if nx_path not in ("IGNORE", "UNCLEAR"): + trg = variadic_path_to_specific_path(nx_path, [self.entry_id, 1]) + res = apply_modifier(modifier, self.yml) + if res is not None: + template[trg] = res return template def report(self, template: dict) -> dict: """Copy data from self into template the appdef instance.""" - self.parse_entry(template) - self.parse_user(template) - self.parse_specimen(template) - self.parse_instrument_header(template) - self.parse_fabrication(template) - self.parse_analysis_chamber(template) - self.parse_reflectron(template) - self.parse_local_electrode(template) - self.parse_detector(template) - self.parse_stage_lab(template) - self.parse_specimen_monitoring(template) - self.parse_control_software(template) - self.parse_pulser(template) - self.parse_reconstruction(template) - self.parse_ranging(template) + self.parse_sample_composition(template) + self.parse_user_section(template) + self.parse_laser_pulser_details(template) + self.parse_other_sections(template) return template diff --git a/pynxtools/definitions b/pynxtools/definitions index e445bf59f..732cc9ed0 160000 --- a/pynxtools/definitions +++ b/pynxtools/definitions @@ -1 +1 @@ -Subproject commit e445bf59fcf547eb0699580e46523ba9f47b2cca +Subproject commit 732cc9ed09d24cb9b36d294ed8fe64d6084ca56f diff --git a/pynxtools/nyaml2nxdl/NXapm.nxdl.xml b/pynxtools/nyaml2nxdl/NXapm.nxdl.xml deleted file mode 100644 index 4d991f59a..000000000 --- a/pynxtools/nyaml2nxdl/NXapm.nxdl.xml +++ /dev/null @@ -1,1696 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Total number of independent wires in the delay-line detector. - - - - - Number of support points for e.g. modeling peaks. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals of this ion type. - - - - - Number of bins in the x direction. - - - - - Number of bins in the y direction. - - - - - Number of bins in the z direction. - - - - - Number of bins. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - - - - - - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - - - - - - - - - - - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - - - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - - - - - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - - - - - - - - - - - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user - in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - - - - - Magnitude of the standard deviation of the grain_diameter. - - - - - The temperature of the last heat treatment step before quenching. - Knowledge about this value can give an idea how the sample - was heat treated, however if available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - - - - - Magnitude of the standard deviation of the heat_treatment_temperature. - - - - - Rate of the last quenching step. - Knowledge about this value can give an idea how the specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - - - - - Magnitude of the standard deviation of the heat_treatment_quenching_rate. - - - - - - The chemical composition of the sample. Typically it is assumed that - this more macroscopic composition is representative for the material - so that the composition of the typically substantially less voluminous - specimen probes from the more voluminous sample. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - - - - - - - - - - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - - - - - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - - - - - Short_name or abbreviation of the specimen name field. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - - - - - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - - - - - - - - - - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - - - - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - - - - - - - Is a reflectron installed and was it used? - - - - - - - - - - - - - - - - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - - - - Identifier of the local_electrode in an e.g. database. - - - - - - - - - - - - - - - - Detector for taking raw time-of-flight and - ion/hit impact positions data. - - - - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - - - - - - Given name/alias. - - - - - - Given brand or model name by the manufacturer. - - - - - Given hardware name/serial number or hash identifier - issued by the manufacturer. - - - - - Given name of the manufacturer. - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - - - - - - - - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - - - - - - - - - - - - - - - - - - - - - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - - - - - - - - - - - - - - Average pressure in the analysis chamber. - - - - - - - - - - - - - - - - Average pressure in the buffer chamber. - - - - - - - - - - - - - - - - Average pressure in the load_lock_chamber. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ - (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) - - - - - - - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ - and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - - - - Ideally measured or best elaborated guess of the - initial radius of the specimen. - - - - - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - - - - - Average detection rate over the course of the experiment. - - - - - - Estimated field at the apex along the evaporation sequence. - - - - - - - - - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - - - - - - - - - - Track time-dependent details over the course of the measurement about the - buffer_chamber. - - - - - Track time-dependent details over the course of the measurement about the - load_lock_chamber. - - - - - Track time-dependent details over the course of the measurement about the - analysis_chamber. - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - - - - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - - - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - - - - - - - - - - - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - - - - - - - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - - - - - - - - - - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - - - - - - - - - Number of pulses since the start of the atom probe - run/evaporation sequence. - - - - - - - - - Hit multiplicity. - - - - - - - - - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - - - - - - - - - - Bitmask which is set to true if the ion - is considered and false otherwise. - - - - - - - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - - - - - - - - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - - - - - - - - - Calibrated time-of-flight. - - - - - - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - - - - - - - - Store vendor-specific calibration models here (if available). - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - - - - - - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - - - - - - - - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - - - - - - - - - - Bin center of mass position along the z axis. - - - - - - - - - Bin center of mass position along the y axis. - - - - - - - - - Bin center of mass position along the x axis. - - - - - - - - - - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - - - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - - - - - - - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - - - - - - - - - Right boundary of each mass-to-charge-state ratio value bin. - - - - - - - - - - - - Details of the background model which was used to - correct the total counts per bin into counts. - - - - - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - - - - - - - - - - diff --git a/pynxtools/nyaml2nxdl/NXapm.yaml b/pynxtools/nyaml2nxdl/NXapm.yaml deleted file mode 100644 index 30729bdf1..000000000 --- a/pynxtools/nyaml2nxdl/NXapm.yaml +++ /dev/null @@ -1,1548 +0,0 @@ -category: application -doc: | - Application definition for atom probe and field ion microscopy experiments. - - This application definition provides a place to document data and metadata to - an atom probe experiment. Primarily the measurement itself is documented. - However, as most atom probe experiments are controlled with commercial software - which does not allow to access the raw detector hits, this application definition - also includes two key groups of processing steps (reconstruction and ranging). - - During tomographic reconstruction measured data are processed into a point cloud - of reconstructed positions of certain ions. During ranging time-of-flight data - are identified as representing specific ions to annotate each ion with a label. - - Commercial software used in atom probe research is designed as an integrated - acquisition and instrument control software. For AMETEK/Cameca local electrode - atom probe (LEAP) instruments the least processed (rawest) numerical results - and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which - are proprietary and their file format specifications not publicly documented. - - Supplementary metadata are kept in a database (formerly known as the ISDb) - which is connected to the instrument control software and synced with the - experiment while ions are detected. In effect, RHIT and HITS files - store the (rawest) experiment data in a closed manner that is - practically useless for users unless they have access to the - commercial software. - - To arrive at a state that atom probe microscopy (APM) with LEAP instruments - delivers a dataset with which users can study reconstructed atomic - position and do e.g. composition analyses or other post-processing - analysis tasks, these raw data have to be processed. Therefore, it is - necessary that for an application definition to be useful, details about - the physical acquisition of the raw data and all its - processing steps have to be stored. - - With this a user can create derived quantities like ion hit positions - (on the detector) and calibrated time-of-flight data. These derived - quantities are also needed to obtain calibrated mass-to-charge-state - ratios, and finally the tomographic reconstruction of the ion positions. - - In most cases, an APM dataset is useful only if it gets post-processed - via so-called ranging. Ranging defines rules for mapping time-of-flight - and mass-to-charge-state ratio values on ion species. This is post-processing - even though in practice it is performed sometimes already (as preview) - already while data are still being collected. - - The ion types decode molecular identities which can very often be - mapped to elemental identities, and also be used to distinguish isotopes. - All these steps are in most cases performed using commercial software. - - Frequently, though, ranging and post-processing is also performed with - (open-source) research software. Therefore, there is strictly speaking - not a single program used throughout an atom probe analysis not even - for the early stage of data acquisition and processing stages to obtain - a useful reconstructed and ranged dataset. - - This application definition documents not only the measurement but also the - key post-processing steps which transform the proprietary data into a - tomographic reconstruction with ranging definitions. - - Future guidance by the technology partners like AMETEK/Cameca could improve - this description to cover a substantial larger number of eventually metadata - that so far are neither publicly documented nor accessible. -symbols: - doc: The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: Total number of ions collected. - n_dld_wires: Total number of independent wires in the delay-line detector. - n_support: Number of support points for e.g. modeling peaks. - n_ivec_max: | - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - n_ranges: | - Number of mass-to-charge-state-ratio intervals of this ion type. - n_x: Number of bins in the x direction. - n_y: Number of bins in the y direction. - n_z: Number of bins in the z direction. - n_bins: Number of bins. - n_topology: Total number of integers in the supplementary XDMF topology array. -# some consistence is not yet achieved with IFES_APT_TC APT HDF5 v1 format -# Language precision: Keywords such as “must” “required” “should”, etc are as per RFC-2119 [RFC2119]. https://tools.ietf.org/html/rfc2119 -# https://gitlab.com/apt_software_toolbox/apt-hdf5 an implementation for an -# IFES APT TC APT HDF5 v1 verifier -# NEW ISSUE: possible offspring application definitions: -# NXapm_opt/pl would be possible, as soon as NXluminescence by Carola Emminger and Florian Dobner is ready whereby -# then there would be two subentries one for an NXapm and one for NXphotoluminesence to capture the photonic atom probe of Rouen/GPM -# and finally if there were an NXapm_afm for atomic force microscopy the IMEC AFM/APT experiments could be stored with an NXapm_afm application definition -# with NXapm and NXafm being respective subentries of the appdef but as NXapm_afm is a step-by-step approach one would have to release the constraint -# that only a single measurement can be performed. -# NXasat which could just take two subentries NXem and NXapm -# NXasat should be a fuse of NXapm and NXem within an NXentry with NXsubentry, in this way we can combine the strength of both application definitions -# to describe also the upcoming technique of atomic scale analytical tomography https://doi.org/10.1017/9781316677292 - -NXapm: - (NXentry): - exists: [min, 1, max, infty] - \@version: - doc: | - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - # enumeration: [sha_256_hash] - definition: - doc: NeXus NXDL schema to which this file conforms. - enumeration: [NXapm] - experiment_identifier: - doc: | - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - experiment_description: - exists: optional - doc: | - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of the application definition behind instead of filling in these - details into the experiment_description free-text description field. - - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information - included when the microscope session started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - experiment was performed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the experiment. The user should be aware that - even with having both dates specified, it may not be possible - to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. - # These computations can take advantage of individual time stamps - # in NXevent_em instances to provide additional pieces of information. - end_time(NX_DATE_TIME): - exists: recommended - doc: | - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. - # NEW ISSUE: fields like duration need a clearer description as to how these - # quantities should be defined. Most atom probers do not care for this other - # than getting an approximate hour-accurate estimate of the time how long it - # took to evaporate the specimen. - # several programs and libraries are usually coupled together for LEAP instruments, - # if it is possible to have a different root version with a different ivas/apsuite - # version that having a single program and version field is not enough but multiple - # are required LAS root version camecaroot version analysis software - - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - run_number: - exists: recommended - doc: | - Neither the specimen_name nor the experiment_identifier but the identifier - through which the experiment is referred to in the control software. - For LEAP instruments it is recommended to use the IVAS/APSuite - run_number. For other instruments, such as the one from Stuttgart or - Oxcart from Erlangen, or the instruments at GPM in Rouen, use the - identifier which is closest in meaning to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact instance which is - generated according to this NXapm application definition. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - - This application definition does currently not allow storing the - entire set of such interrupted runs. Not because of a technical limitation - within NeXus but because we have not seen a covering use case based - on which we could have designed and implemented this case. - Atom probers are invited to contact the respective people in the - FAIRmat team to fix this. - experiment_documentation(NXnote): - exists: optional - doc: | - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - Required for operation_mode apt_fim or other to give further details. - Users should not abuse this field to provide free-text information. - Instead, these pieces of information should be mapped to - respective groups and sections. - thumbnail(NXnote): - exists: optional - doc: | - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - \@type: - operation_mode: - doc: | - What type of atom probe microscopy experiment is performed. - This field is primarily meant to inform materials database systems - to qualitatively filter experiments: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. - - enumeration: [apt, fim, apt_fim, other] - # description: - # exists: optional - # doc: | - (NXuser): - exists: [min, 0, max, infty] - doc: | - Contact information and eventually details person(s) involved in the - microscope session. This can be the principle investigator who performed - this experiment. Adding multiple users if relevant is recommended. - name: - doc: Given (first) name and surname of the user. - affiliation: - exists: recommended - doc: | - Name of the affiliation of the user at the point in time - when the experiment was performed. - address: - exists: recommended - doc: Postal address of the affiliation. - email: - exists: recommended - doc: | - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - orcid: - exists: recommended - doc: | - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific - service should also be written in orcid_platform - orcid_platform: - exists: recommended - doc: | - Name of the OrcID or ResearcherID where the account - under orcid is registered. - telephone_number: - exists: optional - doc: | - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - role: - exists: recommended - doc: | - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - social_media_name: - exists: optional - doc: | - Account name that is associated with the user - in social media platforms. - social_media_platform: - exists: optional - doc: | - Name of the social media platform where the account - under social_media_name is registered. - sample(NXsample): - exists: recommended - doc: | - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about other knowledge they have gained about the sample - from which they cut the specimen which is field-evaporated during the - experiment. Typically this is possible because the atom probe specimen - is usually not heat treated as is but one assumes that one has the sample - prepared as needed (i.e. with a specific grain diameter) and can thus - just cut out the specimen from that material. - - There are cases though where the specimen is processed further, i.e. the - specimen is machined further or exposed to external stimuli during the - experiment. In this case, these details should not be stored in the - sample group but atom probers should make suggestions how this application - definition can be improved to find a better place and compromise - how to improve this application definition. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. - grain_diameter(NX_FLOAT): - exists: optional - doc: | - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size and used in - e.g. Hall-Petch-type materials models this is if at all an ensemble - average whose reporting may be very informative or not if the specimen - contains a few grains only. In atom probe the latter is often the case - because grains are measured partially as their diameter can be in the - order of magnitude of the physical diameter of the specimen. - - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. - unit: NX_LENGTH - grain_diameter_error(NX_FLOAT): - exists: optional - doc: | - Magnitude of the standard deviation of the grain_diameter. - unit: NX_LENGTH - heat_treatment_temperature(NX_FLOAT): - exists: optional - doc: | - The temperature of the last heat treatment step before quenching. - Knowledge about this value can give an idea how the sample - was heat treated, however if available a documentation of the - annealing treatment should be delivered by adding additional files - which are uploaded alongside an NXapm instance. - In the future there should better be an own schema used for the - heat treatment. - unit: NX_TEMPERATURE - heat_treatment_temperature_error(NX_FLOAT): - exists: optional - doc: | - Magnitude of the standard deviation of the heat_treatment_temperature. - unit: NX_TEMPERATURE - heat_treatment_quenching_rate(NX_FLOAT): - exists: optional - doc: | - Rate of the last quenching step. - Knowledge about this value can give an idea how the specimen - was heat treated, however there are many situations where one - can imagine that the scalar value for just the quenching rate, - i.e. the first derivative of the measured time-temperature profile - is itself time-dependant. An example is when the specimen was - left in the furnace after the furnace was switched off. In this case - the specimen cools down with a specific rate of how this furnace - cools down in the lab. Processes which in practice are often not - documented with measuring the time-temperature profile. - - This can be problematic because when the furnace door was left open - or the ambient temperature in the lab changes, i.e. for a series of - experiments where one is conducted on a hot summer - day and the next during winter as might have an effect on the - evolution of the microstructure. There are many cases where this - has been reported to be an issue in industry, e.g. think about aging - aluminium samples left on the factory parking lot on a hot summer - day. - unit: NX_ANY - heat_treatment_quenching_rate_error(NX_FLOAT): - exists: optional - doc: | - Magnitude of the standard deviation of the heat_treatment_quenching_rate. - unit: NX_ANY - description: - exists: optional - (NXchemical_composition): - exists: recommended - doc: | - The chemical composition of the sample. Typically it is assumed that - this more macroscopic composition is representative for the material - so that the composition of the typically substantially less voluminous - specimen probes from the more voluminous sample. - normalization: - doc: | - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation - differs. A normalization based on atom_percent counts relative to the - total number of atoms are of a particular type. By contrast, weight_percent - normalization factorizes in the respective mass of the elements. - Python libraries like pint are challenged by these differences as - at.-% and wt.-% both yield fractional quantities. - enumeration: [atom_percent, weight_percent] - ION(NXion): - exists: [min, 1, max, 118] - name: - doc: | - Human-readable name of the element/ion (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - composition(NX_FLOAT): - doc: | - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - unit: NX_DIMENSIONLESS - composition_error(NX_FLOAT): - doc: | - Magnitude of the standard deviation of the composition (value). - unit: NX_DIMENSIONLESS - specimen(NXsample): - # NEW ISSUE: inject the conclusion from the discussion with Andrea - # according to SAMPLE.yaml 0f8df14 2022/06/15 - # NEW ISSUE: addition of a NXfurnace in which one can define the atmosphere - # and partial pressures of the agents in that atmosphere with which the - # sample was annealed at which temperature see the work happening at PNNL - # NEW ISSUE: it would be good to have an application definition NXicp for chemical composition - name: - doc: | - Descriptive name or ideally (globally) unique persistent identifier. - The name distinguishes the specimen from all others and especially the - predecessor/origin (see the sample group) from where this specimen was cut. - In cases where the specimen was e.g. site-specifically cut from the - sample referred to in the sample group or in cases of an instrument session - during which multiple specimens are loaded, the name has to be descriptive - enough to resolve which specimen on e.g. the microtip array was taken. - - The user is advised to store the details how a specimen was cut/prepared - from a specific sample in the sample_history. The sample_history field - must not be used for writing an alias of the specimen. Instead, - use the field alias for this. As an example there may be a specimen/sample - monitoring system in a lab with bar codes. The bar code is a good - specimen/sample name. A shorter and more human readable alias like - A0 can be an example for something to write in the alias field. - - In cases where multiple specimens have been loaded into the microscope - the name has to be the specific one, whose results are stored - by this NXentry, because a single NXentry is to be used for the - characterization of a single specimen in a single continuous run. - - Details about the specimen preparation should be stored in the - sample_history or if this is not possible in the sample group. - sample_history: - exists: recommended - doc: | - Ideally, a reference to the location of or a (globally) unique - persistent identifier of e.g. another file which should document - ideally as many details as possible of the material, its - microstructure, and its thermo-chemo-mechanical processing/ - preparation history. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider - as being the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing - state and details of the preparation. - preparation_date(NX_DATE_TIME): - exists: recommended - doc: | - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this - should be a part of the sample history, i.e. the sample is imagined - handed over for the analysis. At the point it enters the microscope - the session starts. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Further time stamps prior to preparation_date should - better be placed in resources which describe the sample_history. - alias: - exists: optional - doc: | - Short_name or abbreviation of the specimen name field. - atom_types: - doc: | - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. - description: - exists: optional - doc: | - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. - is_polycrystalline(NX_BOOLEAN): - exists: recommended - doc: | - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - # NEW ISSUE: error model - # NEW ISSUE: use Andrea and MarkusK groups for - # describing the geometry of the sample - (NXdata): - exists: optional - doc: | - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - (NXcoordinate_system_set): - exists: recommended - doc: | - Container to hold different coordinate systems conventions. - - For the specific idea and conventions to use with the - NXcoordinate_system_set inspect the description of the - NXcoordinate_system_set base class. Specific details for application - in atom probe microscopy follow. - - In this research field scientists distinguish usually several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - Coordinate systems should be right-handed ones. - Clockwise rotations should be considered positive rotations. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation ID interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - The transformation here resolves this ambiguity by specifying how - the positive z-axes of either coordinate systems is oriented. - Consult the work of A. J. Breen and B. Gault and team - for further details. - # Spatial transformations are always active transformations; i.e. the location and direction of a vector in one coordinate system is expressed by the following transformation matrix, T Ptransformed = TPoriginal - # add a note about what is the tip space - #Conventions: right-handed, Cartesian, 3D Euclidean CS should be used Laboratory space to be set by This is the space that is set by the chassis of the instrument. The Z direction must be reasonably parallel to gravity (+ve defined to be gravity vector pointing towards lowest ground), but can be defined to be a direction that is nominally parallel to gravity during an experiment. The origin must be placed within a bounding box of the chassis. Tip space instead of specimen space, The space occupied by a tip in the neutral position when ready for analysis. Z+ should be located in the direction of the needle (apex is Z+ from needle centreline). i) If the specimen moves relative to the laboratory frame, and the electrode does not, or if no electrode is present, then the space should be defined such that when the tip is moved physically, it also moves through tip space. ii) If the electrode moves relative to the laboratory frame, then the space should be defined such that, in tip space, the electrode position does not change. - # iii) The transformation between laboratory space and Tip space must be describable by a fixed 3x3 transformation matrix. Detector space: This is a 2D space only, and contains X+ and Y+ directions. X+ and Y+ should indicate primary directions on the detector, and should be, for an equivalent straight-flight-path configuration, such that X+ and Y+ is matched to that of tip space. Laser space missing: Laser space: The coordinate frame describing the impinging wavefront on the sample. Z+ is the vector of the propagating wavefront. X+ is the orthogonal component of the tip direction within the tip-laser plane. The origin shall be placed at the best estimate for tip apex position at the start of the experiment. Reconstruction space : The space occupied by a correctly reconstructed dataset. X+ and Y+ should correspond to X+ and Y+ in the detector space. Z+ should be such that the needle centre line is normal to the detector position. The origin shall be placed at the tip apex. - TRANSFORMATIONS(NXtransformations): - exists: [min, 0, max, infty] - # NEW ISSUE: add Breen's Ultramicroscopy paper on atom probe crystallography - # in what follows each component of the instrument might be equipped with an NXmonitor - (NXmonitor): - exists: [min, 0, max, infty] - # NEW ISSUE ADD AS MANY MONITORS AS NEEDED, also for pressure etc. - # add a default plot V = f(time/evaporation_id), essentially for each quantity - atom_probe(NXinstrument): - doc: | - Metadata and numerical data of the atom probe and the lab in which it - stands. - - An atom probe microscope (experiment) is different compared to a large- - scale facility or electron accelerator experiments in at least two ways: - - * First, ionized atoms and molecular ion(s fragments) - (in the case of atom probe tomography) - and (primarily) imaging gas ions (in the case of field ion - microscopy) are accelerated towards a position-sensitive - and time-of-flight taking detector system. - Hence, there is no real probe/beam. - * Second, the specimen is the lens of the microscope. - - (NXcsg): - exists: optional - instrument_name: - doc: | - Given name of the atom probe at the hosting institution. This is an - alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, - etc. - location: - exists: optional - doc: | - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - flight_path_length(NX_FLOAT): - doc: | - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - unit: NX_LENGTH - # NEW ISSUE: discussion depends on the type of instrument, - # straight flight path, curved, there were a few comments to made - # https://fairmat-experimental.github.io/nexus-fairmat-proposal/ - # 50433d9039b3f33299bab338998acb5335cd8951/classes/ - # contributed_definitions/NXapm.html - # where further details of the flight geometry should be recorded however - # in the majority of cases these data are not offered by APSuite and - # so far nobody has asked or seriously proceeded with how to use these - # pieces of information if they were to be stored - # MK::NEW ISSUE - field_of_view(NX_FLOAT): - exists: recommended - doc: | - The nominal diameter of the specimen ROI which is measured in the - experiment. It is important to mention that the physical specimen - cannot be measured completely because ions may launch but not be - detected or hit elsewhere in the analysis_chamber. - unit: NX_LENGTH - (NXreflectron): - # check if doc string gets carried over doc: Device for reducing flight time differences of ions in ToF experiments. - applied(NX_BOOLEAN): - doc: | - Is a reflectron installed and was it used? - name: - exists: optional - (NXfabrication): - exists: optional - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - description: - exists: recommended - (NXcsg): - exists: optional - # NEW ISSUE: flat_test_data(NXcollection): - # exists: recommended - # doc: NEED FOR FURTHER DISCUSSIONS WITH APM COLLEAGUES WHAT IS RELEVANT HERE. - # NEW ISSUE: have a place to be more specific about the geometry and - # usage of additional lenses: - # for the invizo 6000 instrument it makes sense to add at least groups for the two additional lenses whereby the field of view is brought from 50-60 to at most 100 the key invention - # add: decelerating_electrode(NXlens_em) accelerating_mesh maybe needs an own base class - # I suggest that this section should be reworked with the local_electrode being required and all other components and opposite counter_electrodes being optional WO2016171675A1 details the key specifications of the components and the setup - # see https://en.wikipedia.org/wiki/Einzel_lens for details double einzel lens in the invizo 6000 according to A. Breen (UNSW) - local_electrode(NXlens_em): - doc: | - A local electrode guiding the ion flight path. Also called - counter or extraction electrode. - name: - doc: | - Identifier of the local_electrode in an e.g. database. - (NXaperture_em): - exists: optional - name: - exists: recommended # ##MK::should become required - (NXfabrication): - exists: optional - identifier: - exists: recommended - capabilities: - exists: optional - value(NX_NUMBER): - exists: recommended # ##MK::should become required - (NXcsg): - exists: optional - # but the local_electrode does not really on purpose create a magnetic field, - # specific for an electro-magnetic lens is the symmetry of its field - # NEW ISSUE: for now keep that we have what is an NXlens_em - # NEW ISSUE: APEX MONITOR / LEAP distance monitoring - # NEW ISSUE: the definition of flat test data should be included and documented - # NEW ISSUE: local electrode, baking strategies, storage - ion_detector(NXdetector): - doc: | - Detector for taking raw time-of-flight and - ion/hit impact positions data. - type: - doc: | - Description of the detector type. Specify if the detector is - not the usual type, i.e. not a delay-line detector. - In the case the detector is a multi-channel plate/ - delay line detector, use mcp_dld. In the case the detector is - a phosphor CCD use phosphor_ccd. In other case specify - the detector type via free-text. - # enumeration: [mcp_dld, phosphor_ccd, other] - name: - exists: recommended - doc: Given name/alias. - # NEW ISSUE: why not (NXfabrication) - model: - exists: recommended - doc: Given brand or model name by the manufacturer. - serial_number: - exists: recommended - doc: | - Given hardware name/serial number or hash identifier - issued by the manufacturer. - manufacturer_name: - exists: recommended - doc: Given name of the manufacturer. - signal_amplitude(NX_FLOAT): - exists: optional - doc: | - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - unit: NX_CURRENT - dimensions: - rank: 1 - dim: [[1, n_ions]] - (NXcsg): - exists: optional - pulser(NXpulser_apm): - # NEW ISSUE: other sources of pulsers are possible - # NEW ISSUE: see in WO2016171675A1 Invizo 6000 patent from AMETEK - pulse_mode: - pulse_frequency(NX_FLOAT): - pulse_fraction(NX_FLOAT): - pulsed_voltage(NX_FLOAT): - exists: recommended - standing_voltage(NX_FLOAT): - exists: recommended - (NXcsg): - exists: optional - SOURCE(NXsource): - exists: [min, 0, max, 2] - # INVIZO 6000 instrument have two symmetric lasers! so for these - # laser_gun and laser_beam exists: [min, 0, max, 2] - doc: | - Atom probe microscopes use controlled laser, voltage, or a - combination of pulsing strategies to trigger the excitation - and eventual field evaporation/emission of an ion during - an experiment. - If pulse_mode is set to laser or laser_and_voltage (e.g. for - LEAP6000-type instruments) having the group/section laser_gun - is required and the following of its fields have to be filled: - - * name - * wavelength - * energy - - name: - (NXfabrication): - exists: optional - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - wavelength(NX_FLOAT): - exists: recommended - power(NX_FLOAT): - exists: recommended - pulse_energy(NX_FLOAT): - exists: recommended - laser_beam(NXbeam): - exists: recommended - pinhole_position(NXcollection): # NXsnapshot, NXcg_point_set - exists: recommended - spot_position(NXcollection): # NXsnapshot, NXcg_point_set - exists: recommended - - stage_lab(NXstage_lab): - # NEW ISSUE: consider more detailed opportunities for specifying holders like cryo-controller holder, type of holder, material for pucks make a difference for studies which hunt for hydrogen signal, equally dwell time in buffer and load lock chamber and environmental transfer, the application definition does not account for this at the moment, would need a class representing stage and specimen holder hierarchy of the entire sample loading and transfer system and the contributions or not these components make wrt to contamination. - base_temperature(NX_FLOAT): - doc: | - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - unit: NX_TEMPERATURE - temperature(NX_FLOAT): - exists: optional - doc: | - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - unit: NX_TEMPERATURE - dimensions: - rank: 1 - dim: [[1, n_ions]] - (NXcsg): - exists: optional - # evaporation control in which context is it used? - # NEW ISSUE: begin add and support I/O of further details - # NEW ISSUE: with Shyam Katnagallu fix that so far the application definition does not really cover fim as there is no place to store values for a gas injection system and a (partial) pressure sensor for the imaging gas it should be clarified in the docstring of the pressure field if this measured either a chamber total of a species partial pressure - # NEW ISSUE: add NXapm_energy_analyzer, a voltage grid like done in Rouen/GPM - analysis_chamber(NXchamber): - name: - exists: optional - (NXfabrication): - exists: optional - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - description: - exists: optional - pressure(NX_FLOAT): - doc: | - Average pressure in the analysis chamber. - unit: NX_PRESSURE - (NXcsg): - exists: optional - buffer_chamber(NXchamber): - exists: optional - name: - exists: optional - (NXfabrication): - exists: optional - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - description: - exists: optional - pressure(NX_FLOAT): - doc: | - Average pressure in the buffer chamber. - unit: NX_PRESSURE - (NXcsg): - exists: optional - load_lock_chamber(NXchamber): - exists: optional - name: - exists: optional - (NXfabrication): - exists: optional - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - description: - exists: optional - pressure(NX_FLOAT): - doc: | - Average pressure in the load_lock_chamber. - unit: NX_PRESSURE - (NXcsg): - exists: optional - getter_pump(NXpump): - exists: optional - design: - exists: recommended - (NXfabrication): - exists: optional - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - (NXcsg): - exists: optional - roughening_pump(NXpump): - exists: optional - design: - exists: recommended - (NXfabrication): - exists: optional - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - (NXcsg): - exists: optional - turbomolecular_pump(NXpump): - exists: optional - design: - exists: recommended - (NXfabrication): - exists: optional - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - (NXcsg): - exists: optional - # NEW ISSUE: end add and support I/O of further details - - instrument_calibration(NXcollection): - exists: recommended - doc: | - A possible place, which has to be discussed with the atom probe - community more though, where quantitative details about the calibration - of the counter electrode could be stored. Work in this direction was - e.g. reported by the `Erlangen group `_ - (see `P. Felfer et al. `_ ) - # gridded-counter-electrode shadow image polyline fits are exported as - # NXcg_spline_set see also https://www.youtube.com/watch?v=99hNEkqdj78t=2348s - # NEW ISSUE: dld_signal_amplitude monitoring - # arrival_time_pairs: (recommended) NX_NUMBER (Rank: 3, Dimensions: [n_ions, n_dld_wires, 2]) {units=NX_TIME} - # eventually one may wish to store values from an NXmonitoring tracking the DLD signal amplitude (mV) = f(t) - specimen_monitoring(NXcollection): - exists: recommended - # NEW ISSUE: should be promoted to recommended at some point in particular with closer integration of APM and EM instruments - doc: | - A place where details about the initial shape of the specimen - can be stored. Ideally, here also data about the shape evolution - of the specimen can be stored. There are currently very few - techniques which can measure the shape evolution: - - * Correlative electron microscopy coupled with modeling - but this usually takes an interrupted experiment - in which the specimen is transferred, an image taken, - and a new evaporation sequence initiated. - Examples are `I. Mouton et al. `_ - and `C. Fletcher `_. - * Another method, which is less accurate though, is to monitor - the specimen evolution via the in-built camera system - (if available) in the instrument. - * Another method is to use correlated scanning force microscopy - methods like reported in `C. Fleischmann `_. - * A continuous monitoring of the specimen in a - correlative electron microscopy/atom probe experiment - is planned to be developed by `T. Kelly et al. `_ - Nothing can be said about the outcome of this research yet but - here is where such spatio-temporally data could be stored. - - # NEW ISSUE: consider the above comments into new fields when important progress has been made. - initial_radius(NX_FLOAT): - doc: | - Ideally measured or best elaborated guess of the - initial radius of the specimen. - unit: NX_LENGTH - shank_angle(NX_FLOAT): - doc: | - Ideally measured or best elaborated guess of the shank angle. - This is a measure of the specimen taper. Define it in such a way - that the base of the specimen is modelled as a conical frustrum so - that the shank angle is the (shortest) angle between the specimen - space z-axis and a vector on the lateral surface of the cone. - unit: NX_ANGLE - detection_rate(NX_FLOAT): - doc: | - Average detection rate over the course of the experiment. - unit: NX_DIMENSIONLESS - # NEW ISSUE: define e.g. radius(NX_FLOAT) and evaporation_id(NX_UINT) to store snapshots of the shape evolution of the specimen. - estimated_field_at_the_apex(NX_FLOAT): - exists: optional - doc: | - Estimated field at the apex along the evaporation sequence. - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, n_ions]] - - control_software(NXcollection): - doc: | - The majority of atom probe microscopes come from a - single commercial manufacturer `AMETEK (formerly Cameca) `_. - Their instruments are controlled via an(/a set) of integrated - instrument control system(s) (APSuite/IVAS/DAVis). - - By contrast, instruments which were built by individual - research groups such as of the French (GPM, Rouen, France), - the Schmitz (Inspico, Stuttgart, Germany), - the Felfer (Oxcart, Erlangen, Germany), - the Northwestern (D. Isheim, Seidman group et al.), - or the PNNL group (Pacific Northwest National Laborary, - Portland, Oregon, U.S.) have other solutions - to control the instrument. - - Some of which are modularized and open, - some of which realize also integrated control units with - portions of eventually undisclosed source code and - (so far) lacking (support of)/open APIs. - - Currently, there is no accepted/implemented - community-specific API for getting finely granularized - access to such control settings. - - These considerations motivated the design of the NXapm - application definition in that it stores quantities in NXcollection. - groups to begin with. Holding heterogeneous, not yet standardized - but relevant pieces of information is the purpose of this collection. - # NEW ISSUE: With new development pull fields out of this collection into dedicated groups. - # might consider moving this to individual groups under (NXpump) or (NXchamber) groups. - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - buffer_chamber(NXcollection): - exists: optional - doc: Track time-dependent details over the course of the measurement about the buffer_chamber. - load_lock_chamber(NXcollection): - exists: optional - doc: Track time-dependent details over the course of the measurement about the load_lock_chamber. - analysis_chamber(NXcollection): - exists: optional - doc: Track time-dependent details over the course of the measurement about the analysis_chamber. - # NEW ISSUE: pressure in the buffer and load lock chambers - # NEW ISSUE: atmosphere and partial pressures - - # so although strictly speaking the following steps are computational - # post-processing of detector raw data to be specific they are listed - # under the atom_lab group because for experiment with commercial instrument - # these steps are currently not fully separatable as all processing in - # most cases the processing is done in commercial software. - - status: - exists: recommended - doc: | - A statement whether the measurement was successful or failed prematurely. - enumeration: [success, failure, unknown] - - # NEW ISSUE: atomic volume, detection efficiency, electric field (assumptions), - # final specimen state, pre, post image analysis, a reference to three images - # taken as recommended by cameca, before or after, radius evolution model, field # factor, image compression - - # default statistics would be good to report as output e.g. - # total ions (single, multiple, partial) reconstructed ions (ranged, unranged) - # voltage and bowl calibration (peak) mass_calibration as an own field - - ion_impact_positions(NXprocess): - # NEW ISSUE: check also here the PYCCAPT pipeline from P. Felfer's group - exists: recommended - doc: | - Details about where ions hit the ion_detector and data processing - steps related to analog-to-digital conversion of detector signals - into ion hit positions. For AMETEK LEAP instruments this processing - takes place partly in the control unit of the detector partly - in the software. The process is controlled by the acquisition/ - instrument control software (IVAS/APSuite/DAVis). - The exact details are not documented by AMETEK in an open manner. - For instruments built by individual research groups, - like the Oxcart instrument, individual timing data from the - delay-line detector are openly accessible. - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - arrival_time_pairs(NX_NUMBER): - exists: recommended - doc: | - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - # NEW ISSUE: discuss with Oxcart developers which - # modifications might be necessary here. - unit: NX_TIME - dimensions: - rank: 3 - dim: [[1, n_ions], [2, n_dld_wires], [3, 2]] - hit_positions(NX_NUMBER): - doc: | - Evaluated ion impact coordinates at the detector - (either as computed from the arrival time data - or as reported by the control software). - If the acquisition software enables it one can also store in this - field the hit_positions, as measured by the detector, without any - corrections. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_ions], [2, 2]] - # NEW ISSUE: follow the example of base_temperature_time_profile to monitor the temporal evolution of the detection_rate over the course of the evaporation sequence - # detection_rate_time_profile(NX_FLOAT): - # doc: Spatio-temporal profile of the detection rate since the start of the measurement. - # NEW ISSUE: discuss how to handle cases when we would like to store ideally an array where one dimensions is NX_TIME and the other one is e.g. NX_PERCENT - hit_quality_filtering(NXprocess): - exists: optional - doc: | - This could be a place where currently the publicly undocumented - algorithmic steps are stored how detected hits are judged for their - quality. In CamecaRoot this there is something mentioned like - golden and partial hits, here is where this could be documented. - sequence_index(NX_POSINT): - exists: recommended - hit_multiplicity(NXprocess): - # NEW ISSUE: use symbols to monitor number of pulses - exists: recommended - doc: | - Data post-processing step which is, like the impact position analyses, - usually executed in the integrated control software. This processing - yields how many ions were detected with each pulse. - - It is possible that multiple ions evaporate and hit the same or - different pixels of the detector on the same pulse. - These data form the basis to analyses of the so-called - (hit) multiplicity of an ion. - - Multiplicity must not be confused with how many atoms - f the same element or isotope, respectively, a molecular - ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - pulses_since_last_ion(NX_UINT): - exists: recommended - doc: | - Number of pulses since the last detected ion pulse. - For multi-hit records, after the first record, this is zero. - dimensions: - rank: 1 - dim: [[1, n_ions]] - unit: NX_UNITLESS - pulse_id(NX_UINT): - # NEW ISSUE: I feel the name is misleading, the quantity is - # named like this de facto only because thats the jargon - # term with epos files. - exists: optional - doc: | - Number of pulses since the start of the atom probe - run/evaporation sequence. - dimensions: - rank: 1 - dim: [[1, n_ions]] - unit: NX_UNITLESS - hit_multiplicity(NX_UINT): - # NEW ISSUE: further discussions with members of the APM community - # is required to clarify this field and what it means - doc: | - Hit multiplicity. - dimensions: - rank: 1 - dim: [[1, n_ions]] - unit: NX_UNITLESS - ion_filtering(NXprocess): - exists: recommended - doc: | - Like impact position and hit multiplicity computations, - ion filtering is a data post-processing step with which users - identify which of the detected ions should be included - in the voltage-and-bowl correction. - This post-processing is usually performed via GUI interaction - in the reconstruction pipeline of IVAS/APSuite. - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - evaporation_id_included(NX_BOOLEAN): # NXcs_filter_boolean_mask - doc: | - Bitmask which is set to true if the ion - is considered and false otherwise. - dimensions: - rank: 1 - dim: [[1, n_ions]] # then only a group - - voltage_and_bowl_correction(NXprocess): - # NEW ISSUE: add section for propagation_delay(NXprocess) ? - exists: recommended - doc: | - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - # NEW ISSUE: realistic is that currently scientists can pull always a calibrated time-of-flight - # but not necessarily unprocessed timing data from the detector (unless individuals built the instrument). - # Relevant for ranging are the calibrated data, thats why only these - # (as an intermediate/compromise solution) are required in this version of the application definition - raw_tof(NX_FLOAT): - exists: recommended - doc: | - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - unit: NX_TIME - dimensions: - rank: 1 - dim: [[1, n_ions]] - calibrated_tof(NX_FLOAT): - # NEW ISSUE: which type of calibrations are applied is usually a modified - # sqrt tof to m/q mapping the exact parameter of which are for LEAP instruments not immediately accessible. - doc: | - Calibrated time-of-flight. - unit: NX_TIME - dimensions: - rank: 1 - dim: [[1, n_ions]] - tof_calibration(NXcollection): - exists: recommended - doc: | - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - # NEW ISSUE: should be recommended as otherwise one cannot ensure that - # numerically the same voltage-and-bowl correction results are obtained - # (without knowning the parameters...) - - mass_to_charge_conversion(NXprocess): - exists: recommended - doc: | - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - parameter(NXcollection): - exists: recommended - doc: | - Store vendor-specific calibration models here (if available). - mass_to_charge(NX_FLOAT): - doc: | - Mass-to-charge-state ratio values. - unit: NX_ANY - # \@units: Da / a unitless quantity because it is the charge state and not the charge - dimensions: - rank: 1 - dim: [[1, n_ions]] - - # NEW ISSUE: make this rather an own subentry NXapm_reconstruction - reconstruction(NXprocess): - exists: recommended - doc: | - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - protocol_name: - doc: | - Qualitative statement about which reconstruction protocol was used. - enumeration: [bas, geiser, gault, cameca, other] - parameter: - # NEW ISSUE: the status here should be promoted to required but currently - # one needs to manually extract the reconstruction parameters - # NEW ISSUE: for instance from commercial software, here a better strategy - # is needed how to document the reconstruction parameter. - doc: | - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - # k(NX_FLOAT): - # doc: Field factor - # unit: ?? - # icf(NX_FLOAT): - # doc: Image compression factor. - # unit: ?? - # NEW ISSUE: for AMETEK, as well as for the Bas, Geiser, and - # Gault protocols we know the usual naming of the parameters - # they should be added as optional quantities. - # Therefore, it is difficult for now to generalize the meaning - # and idea behind all relevant reconstruction parameters. - # One could create a class for each reconstruction method, as - # these methods are de facto application definitions. - crystallographic_calibration: - doc: | - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - reconstructed_positions(NX_FLOAT): - doc: | - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_ions], [2, 3]] - visualization(NXprocess): - exists: recommended - xdmf_topology(NX_UINT): - doc: | - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_topology]] - # n_topology == 3*n_ions - xdmf_topology(NX_UINT): - doc: | - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, 36]] - - naive_point_cloud_density_map(NXprocess): - doc: | - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - (NXdata): - doc: | - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - \@signal: - \@axes: - \@AXISNAME_indices: - # \@long_name: - title: - data_counts(NX_NUMBER): - doc: Array of counts for each bin. - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: [[1, n_z], [2, n_y], [3, n_x]] - axis_z(NX_FLOAT): - doc: Bin center of mass position along the z axis. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_z]] - \@long_name: - axis_y(NX_FLOAT): - doc: Bin center of mass position along the y axis. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - axis_x(NX_FLOAT): - doc: Bin center of mass position along the x axis. - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - - # NEW ISSUE: make this rather an own subentry NXapm_ranging - ranging(NXprocess): - exists: recommended - doc: | - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller `_ - * `D. Haley et al. `_ - * `M. Kühbach et al. `_ - - sequence_index(NX_POSINT): - exists: recommended - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - number_of_ion_types(NX_UINT): - doc: | - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - unit: NX_UNITLESS - maximum_number_of_atoms_per_molecular_ion(NX_UINT): - doc: | - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - unit: NX_UNITLESS - - mass_to_charge_distribution(NXprocess): - exists: recommended - doc: | - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - range_minmax(NX_FLOAT): - doc: | - Smallest and largest mass-to-charge-state ratio value. - unit: NX_ANY - # \@units: Da - # NEW ISSUE: NX_ATOMIC_MASS_UNIT use Tommasso scheme here Da - dimensions: - rank: 1 - dim: [[1, 2]] - range_increment(NX_FLOAT): - doc: | - Binning width of the mass-to-charge-state ratio values. - unit: NX_ANY - # \@units: Da - # NEW ISSUE: unit must match with range, is Da - mass_spectrum(NXdata): - doc: | - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - \@signal: - \@axes: - \@AXISNAME_indices: - # \@long_name: - title: - data_counts(NX_NUMBER): - doc: Array of counts for each bin. - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_bins]] - \@long_name: - axis_mass_to_charge(NX_FLOAT): - doc: | - Right boundary of each mass-to-charge-state ratio value bin. - unit: NX_ANY - # \@units: Da - dimensions: - rank: 1 - dim: [[1, n_bins]] - \@long_name: - - background_quantification(NXprocess): - exists: recommended - doc: | - Details of the background model which was used to - correct the total counts per bin into counts. - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - # NEW ISSUE: add parameters of the background model in an e.g. - # NXcollection as these are specific to every background model - # NEW ISSUE: touching upon i.e. research activities by Andrew London et al. - # substantiating the need for a clearer description how peak/signals were - # eventually processed via deconvolution methods - - peak_search_and_deconvolution(NXprocess): - exists: recommended - doc: | - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - (NXpeak): - exists: [min, 0, max, infty] - label: - exists: recommended - peak_model: - doc: | - THIS DOCSTRING NEEDS CLARIFICATION. - - peak_identification(NXprocess): - exists: recommended - doc: | - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - (NXprogram): - exists: [min, 1, max, infty] - program: - \@version: - (NXion): - exists: [min, 0, max, 256] - isotope_vector(NX_UINT): - charge_state(NX_INT): - mass_to_charge_range(NX_FLOAT): - nuclid_list(NX_UINT): - exists: recommended - name: - exists: recommended diff --git a/tests/data/dataconverter/readers/apm/nomad_oasis_eln_schema_for_nx_apm/nxapm.schema.archive.yaml b/tests/data/dataconverter/readers/apm/nomad_oasis_eln_schema_for_nx_apm/nxapm.schema.archive.yaml index e27a61167..ba4a00b3b 100644 --- a/tests/data/dataconverter/readers/apm/nomad_oasis_eln_schema_for_nx_apm/nxapm.schema.archive.yaml +++ b/tests/data/dataconverter/readers/apm/nomad_oasis_eln_schema_for_nx_apm/nxapm.schema.archive.yaml @@ -381,7 +381,7 @@ definitions: maxValue: 10.0 field_of_view: type: np.float64 - unit: meter + unit: nanometer description: | The nominal diameter of the specimen ROI which is measured in the experiment. Physically, the specimen cannot be measured completely @@ -389,7 +389,7 @@ definitions: m_annotations: eln: component: NumberEditQuantity - defaultDisplayUnit: meter + defaultDisplayUnit: nanometer minValue: 0.0 fabrication_vendor: type: str @@ -479,7 +479,7 @@ definitions: component: NumberEditQuantity defaultDisplayUnit: kelvin minValue: 0.0 - maxValue: 273.15 + maxValue: 300.0 analysis_chamber_pressure: type: np.float64 unit: torr @@ -549,8 +549,8 @@ definitions: type_kind: Enum type_data: - laser - - high_voltage - - laser_and_high_voltage + - voltage + - laser_and_voltage description: | Which pulsing mode was used? m_annotations: @@ -574,41 +574,53 @@ definitions: component: NumberEditQuantity minValue: 0.0 maxValue: 1.0 - laser_source_name: - type: str - description: Given name/alias. - m_annotations: - eln: - component: StringEditQuantity - laser_source_wavelength: - type: np.float64 - unit: meter - description: Nominal wavelength of the laser radiation. - m_annotations: - eln: - component: NumberEditQuantity - defaultDisplayUnit: nanometer - minValue: 0.0 - laser_source_power: - type: np.float64 - unit: watt - description: | - Nominal power of the laser source while - illuminating the specimen. - m_annotations: - eln: - component: NumberEditQuantity - defaultDisplayUnit: nanowatt - minValue: 0.0 - laser_source_pulse_energy: - type: np.float64 - unit: joule - description: Average energy of the laser at peak of each pulse. - m_annotations: - eln: - component: NumberEditQuantity - defaultDisplayUnit: picojoule - minValue: 0.0 + # LEAP 6000 instrument has up to two lasers + sub_sections: + laser_source: + repeats: True + section: + description: | + Details about each laser pulsing unit. + LEAP6000 instruments can use up to two lasers. + m_annotations: + eln: + quantities: + name: + type: str + description: Given name/alias. + m_annotations: + eln: + component: StringEditQuantity + wavelength: + type: np.float64 + unit: nanometer + description: Nominal wavelength of the laser radiation. + m_annotations: + eln: + component: NumberEditQuantity + defaultDisplayUnit: nanometer + minValue: 0.0 + power: + type: np.float64 + unit: nanowatt + description: | + Nominal power of the laser source while + illuminating the specimen. + m_annotations: + eln: + component: NumberEditQuantity + defaultDisplayUnit: nanowatt + minValue: 0.0 + pulse_energy: + type: np.float64 + unit: picojoule + description: | + Average energy of the laser at peak of each pulse. + m_annotations: + eln: + component: NumberEditQuantity + defaultDisplayUnit: picojoule + minValue: 0.0 # control_software: # section: # description: Which control software was used e.g. IVAS/APSuite From 5ff040da3dd784c98880db66da8dc6736010734b Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Mon, 12 Jun 2023 12:23:38 +0200 Subject: [PATCH 06/18] Implemented parsing of composition from ELN, completed code styling, and tested the apm dataconverter, modified standalone ipynb, apm reader is fully functional again, next step, check that em_nion reader remains functional after the refactoring of the ELN utility functions and use the same mapping refactoring for em_spctrscpy and em_om reader --- examples/apm/Write.NXapm.Example.1.ipynb | 22 ++- examples/apm/apm.oasis.specific.yaml | 1 + examples/apm/eln_data_apm.yaml | 142 ++++++++------ pynxtools/dataconverter/readers/apm/reader.py | 6 +- .../readers/apm/utils/apm_load_generic_eln.py | 36 +++- .../apm/utils/apm_parse_composition_table.py | 179 ++++++++++++++++++ pynxtools/definitions | 2 +- 7 files changed, 327 insertions(+), 61 deletions(-) create mode 100644 examples/apm/apm.oasis.specific.yaml create mode 100644 pynxtools/dataconverter/readers/apm/utils/apm_parse_composition_table.py diff --git a/examples/apm/Write.NXapm.Example.1.ipynb b/examples/apm/Write.NXapm.Example.1.ipynb index efae762e3..d3a79abcd 100644 --- a/examples/apm/Write.NXapm.Example.1.ipynb +++ b/examples/apm/Write.NXapm.Example.1.ipynb @@ -195,6 +195,20 @@ "### **Step 3c**: Convert the files in the example into an NXapm-compliant NeXus/HDF5 file." ] }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "The deployment_specific YAML file can be used to simplify a specific ELN, e.g. to avoid having to type
\n", + "repetitive information. A typical use case is an OASIS in a laboratory where there is a fixed number of
\n", + "instruments for which many details stay the same, these can be carried over via a *.oasis.specific.yaml file.
\n", + "It is the responsibility of the OASIS maintainer to document and version these specific configurations.
\n", + "We would be happy to learn how this functionality is useful and learn about your feedback to improve
\n", + "this feature to make working with NeXus and ELNs more convenient.
\n", + "
" + ] + }, { "cell_type": "code", "execution_count": null, @@ -205,6 +219,7 @@ "source": [ "#parser-nexus/tests/data/tools/dataconverter/readers/em_om/\n", "eln_data_file_name = [\"eln_data_apm.yaml\"]\n", + "deployment_specific = [\"apm.oasis.specific.yaml\"]\n", "input_recon_file_name = [\"Si.apt\",\n", " \"Si.epos\",\n", " \"Si.pos\",\n", @@ -227,12 +242,13 @@ " \"apm.case6.nxs\"]\n", "for case_id in [0]:\n", " ELN = eln_data_file_name[0]\n", + " OASIS = deployment_specific[0]\n", " INPUT_RECON = input_recon_file_name[case_id]\n", " INPUT_RANGE = input_range_file_name[case_id]\n", " OUTPUT = output_file_name[case_id]\n", "\n", - " ! dataconverter --reader apm --nxdl NXapm --input-file $ELN --input-file \\\n", - " $INPUT_RECON --input-file $INPUT_RANGE --output $OUTPUT" + " ! dataconverter --reader apm --nxdl NXapm --input-file $ELN --input-file $OASIS \\\n", + " --input-file $INPUT_RECON --input-file $INPUT_RANGE --output $OUTPUT" ] }, { @@ -527,7 +543,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.16" + "version": "3.10.6" } }, "nbformat": 4, diff --git a/examples/apm/apm.oasis.specific.yaml b/examples/apm/apm.oasis.specific.yaml new file mode 100644 index 000000000..82394f07e --- /dev/null +++ b/examples/apm/apm.oasis.specific.yaml @@ -0,0 +1 @@ +location: Leoben diff --git a/examples/apm/eln_data_apm.yaml b/examples/apm/eln_data_apm.yaml index 11e29ced4..ddd67ebcf 100644 --- a/examples/apm/eln_data_apm.yaml +++ b/examples/apm/eln_data_apm.yaml @@ -1,82 +1,118 @@ atom_probe: analysis_chamber_pressure: unit: torr - value: 1.0e-10 + value: 2.0e-10 control_software_program: IVAS - control_software_program__attr_version: 3.6.4 - fabrication_capabilities: n/a - fabrication_identifier: n/a + control_software_program__attr_version: 3.6.8 + fabrication_identifier: '12' fabrication_model: LEAP3000 - fabrication_vendor: AMETEK/Cameca + fabrication_vendor: Cameca + field_of_view: + unit: nm + value: 20. flight_path_length: unit: m - value: 0.9 - instrument_name: LEAP 3000 - ion_detector_model: cameca - ion_detector_name: none + value: 1.2 + instrument_name: LEAP + ion_detector_model: n/a + ion_detector_name: n/a ion_detector_serial_number: n/a ion_detector_type: mcp_dld - local_electrode_name: electrode 1 + local_electrode_name: L1 + location: Denton pulser: - laser_source_name: laser - laser_source_power: - unit: W - value: 2.0e-08 - laser_source_pulse_energy: - unit: J - value: 1.2e-11 - laser_source_wavelength: - unit: m - value: 4.8e-07 - pulse_fraction: 0.1 + laser_source: + - name: laser1 + power: + unit: nW + value: 24.0 + pulse_energy: + unit: pJ + value: 24.0 + wavelength: + unit: nm + value: 355.0 + - name: laser2 + power: + unit: nW + value: 12.0 + pulse_energy: + unit: pJ + value: 12.0 + wavelength: + unit: nm + value: 254.0 + pulse_fraction: 0.8 pulse_frequency: unit: kHz - value: 250 - pulse_mode: laser + value: 250.0 + pulse_mode: laser_and_voltage reflectron_applied: true - specimen_monitoring_detection_rate: 0.6 + specimen_monitoring_detection_rate: 0.8 specimen_monitoring_initial_radius: unit: nm - value: 30 + value: 12.0 specimen_monitoring_shank_angle: unit: ° - value: 5 + value: 5.0 stage_lab_base_temperature: unit: K - value: 30 + value: 20.0 status: success entry: - attr_version: nexus-fairmat-proposal successor of 9636feecb79bb32b828b1a9804269573256d7696 - definition: NXapm - end_time: '2022-09-22T20:00:00+00:00' - experiment_description: some details for nomad, ODS steel precipitates for testing - a developmental clustering algorithm called OPTICS. - experiment_identifier: R31-06365-v02 + experiment_description: '

Normal

+ +

Bold

+ +

Italics

' + experiment_identifier: Si test + start_time: '2023-06-11T11:20:00+00:00' + end_time: '2023-06-11T11:20:00+00:00' + run_number: '2121' operation_mode: apt - program: IVAS - program__attr_version: 3.6.4 - run_number: '6365' - start_time: '2022-09-20T20:00:00+00:00' ranging: program: IVAS - program__attr_version: 3.6.4 + program__attr_version: 3.6.8 reconstruction: crystallographic_calibration: n/a - parameter: kf = 1.8, ICF = 1.02, Vat = 60 at/nm^3 + parameter: kf = 1.8, icf = 3.3 program: IVAS - program__attr_version: 3.6.4 - protocol_name: cameca + program__attr_version: 3.6.8 + protocol_name: bas +sample: + composition: + - Mo + - Al 12 +- 3 + - B 50 ppm +- 12 + - C 3.6 + grain_diameter: + unit: µm + value: 200.0 + grain_diameter_error: + unit: µm + value: 50.0 + heat_treatment_quenching_rate: + unit: K / s + value: 150.0 + heat_treatment_quenching_rate_error: + unit: K / s + value: 10.0 + heat_treatment_temperature: + unit: K + value: 600.0 + heat_treatment_temperature_error: + unit: K + value: 20.0 specimen: - atom_types: - - Fe - - Cr - - Y - - O - description: ODS steel, i.e. material with Y2O3 dispersoids - name: ODS-Specimen 1 - preparation_date: '2022-09-12T20:01:00+00:00' - sample_history: undocumented - short_title: ODS + alias: Si + description: '

normal

+ +

bold

+ +

italics

' + is_polycrystalline: true + name: usa_denton_smith_si + preparation_date: '2023-06-11T12:51:00+00:00' user: -- name: Jing Wang -- name: Daniel Schreiber +- {} +- {} diff --git a/pynxtools/dataconverter/readers/apm/reader.py b/pynxtools/dataconverter/readers/apm/reader.py index 4ab082496..2e946257f 100644 --- a/pynxtools/dataconverter/readers/apm/reader.py +++ b/pynxtools/dataconverter/readers/apm/reader.py @@ -129,9 +129,9 @@ def read(self, print("Create NeXus default plottable data...") apm_default_plot_generator(template, n_entries) - print("Reporting state of template before passing to HDF5 writing...") - for keyword in template.keys(): - print(keyword) + # print("Reporting state of template before passing to HDF5 writing...") + # for keyword in template.keys(): + # print(keyword) # print(template[keyword]) print("Forward instantiated template to the NXS writer...") diff --git a/pynxtools/dataconverter/readers/apm/utils/apm_load_generic_eln.py b/pynxtools/dataconverter/readers/apm/utils/apm_load_generic_eln.py index 2cdf8794a..ed36eec23 100644 --- a/pynxtools/dataconverter/readers/apm/utils/apm_load_generic_eln.py +++ b/pynxtools/dataconverter/readers/apm/utils/apm_load_generic_eln.py @@ -23,7 +23,7 @@ import yaml -# from ase.data import chemical_symbols +from ase.data import chemical_symbols from pynxtools.dataconverter.readers.apm.map_concepts.apm_eln_to_nx_map \ import NxApmElnInput, NxUserFromListOfDict @@ -31,6 +31,9 @@ from pynxtools.dataconverter.readers.shared.map_concepts.mapping_functors \ import variadic_path_to_specific_path, apply_modifier +from pynxtools.dataconverter.readers.apm.utils.apm_parse_composition_table \ + import parse_composition_table + class NxApmNomadOasisElnSchemaParser: # pylint: disable=too-few-public-methods """Parse eln_data.yaml dump file content generated from a NOMAD OASIS YAML. @@ -65,6 +68,37 @@ def __init__(self, file_name: str, entry_id: int): def parse_sample_composition(self, template: dict) -> dict: """Interpret human-readable ELN input to generate consistent composition table.""" + src = "sample/composition" + if src in self.yml.keys(): + if isinstance(self.yml[src], list): + dct = parse_composition_table(self.yml[src]) + + prfx = f"/ENTRY[entry{self.entry_id}]/sample/" \ + f"CHEMICAL_COMPOSITION[chemical_composition]" + unit = "at.-%" # the assumed default unit + if "normalization" in dct: + if dct["normalization"] in ["%", "at%", "at-%", "at.-%", "ppm", "ppb"]: + unit = "at.-%" + template[f"{prfx}/normalization"] = "atom_percent" + elif dct["normalization"] in ["wt%", "wt-%", "wt.-%"]: + unit = "wt.-%" + template[f"{prfx}/normalization"] = "weight_percent" + else: + return template + ion_id = 1 + for symbol in chemical_symbols[1::]: + # ase convention, chemical_symbols[0] == "X" + # to use ordinal number for indexing + if symbol in dct: + if isinstance(dct[symbol], tuple) and len(dct[symbol]) == 2: + trg = f"{prfx}/ION[ion{ion_id}]" + template[f"{trg}/name"] = symbol + template[f"{trg}/composition"] = dct[symbol][0] + template[f"{trg}/composition/@units"] = unit + if dct[symbol][1] is not None: + template[f"{trg}/composition_error"] = dct[symbol][1] + template[f"{trg}/composition_error/@units"] = unit + ion_id += 1 return template def parse_user_section(self, template: dict) -> dict: diff --git a/pynxtools/dataconverter/readers/apm/utils/apm_parse_composition_table.py b/pynxtools/dataconverter/readers/apm/utils/apm_parse_composition_table.py new file mode 100644 index 000000000..cf8f2bc56 --- /dev/null +++ b/pynxtools/dataconverter/readers/apm/utils/apm_parse_composition_table.py @@ -0,0 +1,179 @@ +# +# Copyright The NOMAD Authors. +# +# This file is part of NOMAD. See https://nomad-lab.eu for further info. +# +# Licensed under the Apache License, Version 2.0 (the "License"); +# you may not use this file except in compliance with the License. +# You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. +# +"""Parse human-readable composition infos from set of ELN string text fields.""" + +# pylint: disable=no-member,too-many-branches + +import re + +import numpy as np + +from ase.data import chemical_symbols + + +def parse_human_readable_composition_case_one(symbol): + """Handle specification of matrix or remainder element.""" + return ("define_matrix", symbol, None, None, None) + + +def parse_human_readable_composition_case_two(args, symbol): + """Handle case element and at.-% composition, no comp. stdev.""" + if args[1] in ["rem", "remainder", "matrix"]: + return ("define_matrix", symbol, None, None, None) + composition = re.match(r"[-+]?(?:\d*\.*\d+)", args[1]) + if composition is not None: + fraction = np.float64(composition[0]) + return ("add_element", symbol, fraction, None, "at.-%") + return (None, None, None, None, None) + + +def parse_human_readable_composition_case_three(human_input, args, symbol): + """Handle case element with different than default normalization, no comp. stdev.""" + composition = re.findall(r"[-+]?(?:\d*\.*\d+)", human_input) + if len(composition) == 1: + fraction = np.float64(composition[0]) + normalization = args[2] + if normalization in ["%", "at%", "at-%", "at.-%"]: + return ("add_element", symbol, fraction, None, "at.-%") + if normalization in ["wt%", "wt-%", "wt.-%"]: + return ("add_element", symbol, fraction, None, "wt.-%") + if normalization == "ppm": + return ("add_element", symbol, fraction / 1.0e4, None, "at.-%") + if normalization == "ppb": + return ("add_element", symbol, fraction / 1.0e7, None, "at.-%") + return (None, None, None, None, None) + + +def parse_human_readable_composition_case_four(human_input, symbol): + """Handle case at.-% normalization with comp. stdev.""" + composition = re.findall(r"[-+]?(?:\d*\.*\d+)", human_input) + composition_error = human_input.count("+-") + if (len(composition) == 2) and (composition_error == 1): + fraction = np.float64(composition[0]) + error = np.float64(composition[1]) + return ("add_element", symbol, fraction, error, "at.-%") + return (None, None, None, None, None) + + +def parse_human_readable_composition_case_five(human_input, args, symbol): + """Handle case with different than standard normalization and comp. stdev.""" + composition = re.findall(r"[-+]?(?:\d*\.*\d+)", human_input) + if (len(composition) == 2) and (human_input.count("+-") == 1): + fraction = np.float64(composition[0]) + error = np.float64(composition[1]) + normalization = args[2] + if normalization in ["%", "at%", "at-%", "at.-%"]: + return ("add_element", symbol, fraction, error, "at.-%") + if normalization in ["wt%", "wt-%", "wt.-%"]: + return ("add_element", symbol, fraction, error, "wt.-%") + if normalization == "ppm": + return ("add_element", symbol, fraction / 1.0e4, error / 1.0e4, "at.-%") + if normalization == "ppb": + return ("add_element", symbol, fraction / 1.0e7, error / 1.0e7, "at.-%") + return (None, None, None, None, None) + + +def parse_human_readable_composition_information(eln_input): + """Identify instruction to parse from eln_input to define composition table.""" + args = eln_input.split(" ") + if len(args) >= 1: + element_symbol = args[0] + # composition value argument fraction is always expected in percent + # i.e. human should have written 98 instead 0.98! + if (element_symbol != "X") and (element_symbol in chemical_symbols): + # case: "Mo" + if len(args) == 1: + return parse_human_readable_composition_case_one( + element_symbol) + # case: "Mo matrix" or "Mo 98.0", always assuming at.-%! + if len(args) == 2: + return parse_human_readable_composition_case_two( + args, element_symbol) + # case: "Mo 98 wt.-%", selectable at.-%, ppm, ppb, or wt.-%! + if len(args) == 3: + return parse_human_readable_composition_case_three( + eln_input, args, element_symbol) + # case: "Mo 98 +- 2", always assuming at.-%! + if len(args) == 4: + return parse_human_readable_composition_case_four( + eln_input, element_symbol) + # case: "Mo 98 wt.-% +- 2", selectable at.-%, ppm, ppb, or wt.-%! + if len(args) == 5: + return parse_human_readable_composition_case_five( + eln_input, args, element_symbol) + return (None, None, None, None, None) + + +def parse_composition_table(composition_list): + """Check if all the entries in the composition list yield a valid composition table.""" + composition_table = {} + # check that there are no contradictions or inconsistenc + for entry in composition_list: + instruction, element, composition, stdev, normalization \ + = parse_human_readable_composition_information(entry) + # print(f"{instruction}, {element}, {composition}, {stdev}, {normalization}") + + if instruction == "add_element": + if "normalization" not in composition_table: + if normalization is not None: + composition_table["normalization"] = normalization + else: + # as the normalization model is already defined, all following statements + # need to comply because we assume we are not allowed to mix atom and weight + # percent normalization in a composition_table + if normalization is not None: + if normalization != composition_table["normalization"]: + raise ValueError("Composition list is contradicting as it \ + mixes atom- with weight-percent normalization!") + + if element not in composition_table: + composition_table[element] = (composition, stdev) + else: + raise ValueError("Composition list is incorrectly formatted as if has \ + at least multiple lines for the same element!") + continue + if instruction == "define_matrix": + if element not in composition_table: + composition_table[element] = (None, None) + # because the fraction is unclear at this point + else: + raise ValueError("Composition list is contradicting as it includes \ + at least two statements what the matrix should be!") + + # determine remaining fraction + total_fractions = 0. + remainder_element = None + for keyword, tpl in composition_table.items(): + if keyword != "normalization": + if (tpl is not None) and (tpl != (None, None)): + total_fractions += tpl[0] + else: + remainder_element = keyword + # print(f"Total fractions {total_fractions}, remainder element {remainder_element}") + if remainder_element is None: + raise ValueError("Composition list inconsistent because either fractions for \ + elements do not add up to 100. or no symbol for matrix defined!") + + if composition_table: # means != {} + composition_table[remainder_element] = (1.0e2 - total_fractions, None) + # error propagation model required + + # document if reporting as percent or fractional values + composition_table["percent"] = True + + return composition_table diff --git a/pynxtools/definitions b/pynxtools/definitions index 732cc9ed0..5bf6c2dd7 160000 --- a/pynxtools/definitions +++ b/pynxtools/definitions @@ -1 +1 @@ -Subproject commit 732cc9ed09d24cb9b36d294ed8fe64d6084ca56f +Subproject commit 5bf6c2dd75043935bd503be8d0394f1d724a2fb5 From ee51012551a4404d8a15512886c0cba5a51ee3c9 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Thu, 20 Jul 2023 11:47:24 +0200 Subject: [PATCH 07/18] Bumped defs to match those from the fairmat 2023 nexus code camp results via the fairmat_2023_pullback branch --- pynxtools/definitions | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pynxtools/definitions b/pynxtools/definitions index f91c66d50..4188634b2 160000 --- a/pynxtools/definitions +++ b/pynxtools/definitions @@ -1 +1 @@ -Subproject commit f91c66d50d377d3bbda24c55e3f2c4bdfbc6075f +Subproject commit 4188634b21a6f5c4491e964412c70df63e495b54 From 28a8433a182b87f7d3a7ef1bbf74f0593c65b28a Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Thu, 20 Jul 2023 14:02:27 +0200 Subject: [PATCH 08/18] Tested apm, em examples with fairmat_2023_pullback branch defs --- examples/apm/Write.NXapm.Example.1.ipynb | 17 ++++++++++------- .../em_nion/Write.NXem_nion.Example.1.ipynb | 14 +++++++++++--- examples/em_om/Write.NXem_ebsd.Example.1.ipynb | 8 +++++--- .../em_spctrscpy/Write.NXem.Example.1.ipynb | 8 ++++---- .../readers/em_om/utils/image_transform.py | 8 +++----- pynxtools/definitions | 2 +- 6 files changed, 34 insertions(+), 23 deletions(-) diff --git a/examples/apm/Write.NXapm.Example.1.ipynb b/examples/apm/Write.NXapm.Example.1.ipynb index d3a79abcd..43b04a818 100644 --- a/examples/apm/Write.NXapm.Example.1.ipynb +++ b/examples/apm/Write.NXapm.Example.1.ipynb @@ -218,6 +218,7 @@ "outputs": [], "source": [ "#parser-nexus/tests/data/tools/dataconverter/readers/em_om/\n", + "import numpy as np\n", "eln_data_file_name = [\"eln_data_apm.yaml\"]\n", "deployment_specific = [\"apm.oasis.specific.yaml\"]\n", "input_recon_file_name = [\"Si.apt\",\n", @@ -240,7 +241,7 @@ " \"apm.case4.nxs\",\n", " \"apm.case5.nxs\",\n", " \"apm.case6.nxs\"]\n", - "for case_id in [0]:\n", + "for case_id in np.arange(0, 3 + 1):\n", " ELN = eln_data_file_name[0]\n", " OASIS = deployment_specific[0]\n", " INPUT_RECON = input_recon_file_name[case_id]\n", @@ -433,7 +434,7 @@ "cell_type": "markdown", "metadata": {}, "source": [ - "
\n", + "
\n", "Currently, this functionality requires a Python environment with a newer version of the ase library than the one
\n", "which is used by the installation of pynxtools (which is currently ase==3.19.0). Instead, ase>=3.22.1 should be used.
\n", "The issue with the specific functionalities used in the *create_reconstructed_positions* function is that when using
\n", @@ -464,12 +465,14 @@ "cell_type": "markdown", "metadata": {}, "source": [ - "
\n", - "This functionality uses recent features of ase which demands an environment that is currently not supported
\n", + "
\n", + "This functionality uses recent features of ase which demands an environment that is not necessarily supported
\n", "by NOMAD OASIS. As the here exemplified settings for this example are configured to represent an environment
\n", - "matching close to NOMAD users who are interested in this developer functionality should do the following:
\n", + "matching one which is close to NOMAD, users who are interested in this dev functionality should do the following:
\n", "Run this example in a standalone environment where ase is upgraded to the latest version and then use
\n", "the generated NeXus files either as is or upload them to NOMAD OASIS.
\n", + "If the above-mentioned cell detects e.g. that a recent version of ase was installed
\n", + "(e.g. >3.22.x) then the code in the following cell can be executed without issues.
\n", "
" ] }, @@ -512,7 +515,7 @@ "metadata": {}, "source": [ "### Contact person for the apm reader and related examples in FAIRmat:\n", - "Markus Kühbach, 2023/05
\n", + "Markus Kühbach, 2023/07/20
\n", "\n", "### Funding\n", "FAIRmat is a consortium on research data management which is part of the German NFDI.
\n", @@ -543,7 +546,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.10.6" + "version": "3.9.12" } }, "nbformat": 4, diff --git a/examples/em_nion/Write.NXem_nion.Example.1.ipynb b/examples/em_nion/Write.NXem_nion.Example.1.ipynb index af08fdd0e..452f1d2c3 100644 --- a/examples/em_nion/Write.NXem_nion.Example.1.ipynb +++ b/examples/em_nion/Write.NXem_nion.Example.1.ipynb @@ -88,7 +88,15 @@ "metadata": {}, "outputs": [], "source": [ - "! wget https://www.zenodo.org/record/7986279/files/ger_berlin_haas_nionswift_multimodal.zip\n", + "! wget https://www.zenodo.org/record/7986279/files/ger_berlin_haas_nionswift_multimodal.zip" + ] + }, + { + "cell_type": "code", + "execution_count": null, + "metadata": {}, + "outputs": [], + "source": [ "zp.ZipFile(\"ger_berlin_haas_nionswift_multimodal.zip\").extractall(path=\"\", members=None, pwd=None)" ] }, @@ -240,7 +248,7 @@ "metadata": {}, "source": [ "### Contact person for the em_nion reader and related examples in FAIRmat:\n", - "Markus Kühbach, 2023/05
\n", + "Markus Kühbach, 2023/07/20
\n", "\n", "### Funding\n", "FAIRmat is a consortium on research data management which is part of the German NFDI.
\n", @@ -271,7 +279,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.10.6" + "version": "3.9.12" } }, "nbformat": 4, diff --git a/examples/em_om/Write.NXem_ebsd.Example.1.ipynb b/examples/em_om/Write.NXem_ebsd.Example.1.ipynb index dd62925fb..849da865f 100644 --- a/examples/em_om/Write.NXem_ebsd.Example.1.ipynb +++ b/examples/em_om/Write.NXem_ebsd.Example.1.ipynb @@ -259,11 +259,13 @@ "cell_type": "code", "execution_count": null, "metadata": { + "scrolled": true, "tags": [] }, "outputs": [], "source": [ "#parser-nexus/tests/data/tools/dataconverter/readers/em_om/\n", + "import numpy as np\n", "eln_data_file_name = [\"eln_data_em_om.yaml\"]\n", "input_data_file_name = [\"PrcShanghaiShi.EBSPs70deg.zip\",\n", " \"H5OINA_examples_Specimen_1_Map_EDS_+_EBSD_Map_Data_2.h5oina\",\n", @@ -273,7 +275,7 @@ " \"em_om.case2.nxs\",\n", " \"em_om.case3e.nxs\",\n", " \"em_om.case4.nxs\"]\n", - "for case_id in [4]: # [0, 1, 2, 3]:\n", + "for case_id in np.arange(0, 3 + 1):\n", " ELN = eln_data_file_name[0]\n", " INPUT = input_data_file_name[case_id]\n", " OUTPUT = output_file_name[case_id]\n", @@ -338,7 +340,7 @@ "metadata": {}, "source": [ "### Contact person for the apm reader and related examples in FAIRmat:\n", - "Markus Kühbach, 2023/05
\n", + "Markus Kühbach, 2023/07/20
\n", "\n", "### Funding\n", "FAIRmat is a consortium on research data management which is part of the German NFDI.
\n", @@ -362,7 +364,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.16" + "version": "3.9.12" }, "vscode": { "interpreter": { diff --git a/examples/em_spctrscpy/Write.NXem.Example.1.ipynb b/examples/em_spctrscpy/Write.NXem.Example.1.ipynb index 61b0f33d3..80455b2c2 100644 --- a/examples/em_spctrscpy/Write.NXem.Example.1.ipynb +++ b/examples/em_spctrscpy/Write.NXem.Example.1.ipynb @@ -239,9 +239,9 @@ "outputs": [], "source": [ "# H5Web(OUTPUT)\n", - "# H5Web(\"em_sp.case1.nxs\")\n", + "H5Web(\"em_sp.case1.nxs\")\n", "# H5Web(\"em_sp.case2.nxs\")\n", - "H5Web(\"em_sp.case3.nxs\")" + "# H5Web(\"em_sp.case3.nxs\")" ] }, { @@ -305,7 +305,7 @@ "metadata": {}, "source": [ "### Contact person for the apm reader and related examples in FAIRmat:\n", - "Markus Kühbach, 2023/05
\n", + "Markus Kühbach, 2023/07/20
\n", "\n", "### Funding\n", "FAIRmat is a consortium on research data management which is part of the German NFDI.
\n", @@ -336,7 +336,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.16" + "version": "3.9.12" }, "vscode": { "interpreter": { diff --git a/pynxtools/dataconverter/readers/em_om/utils/image_transform.py b/pynxtools/dataconverter/readers/em_om/utils/image_transform.py index 34f98266f..8a11afc77 100644 --- a/pynxtools/dataconverter/readers/em_om/utils/image_transform.py +++ b/pynxtools/dataconverter/readers/em_om/utils/image_transform.py @@ -39,16 +39,14 @@ def thumbnail(img, size=300): return img if old_width == old_height: - img.thumbnail((size, size), pil.ANTIALIAS) - + img.thumbnail((size, size)) elif old_height > old_width: ratio = float(old_width) / float(old_height) new_width = ratio * size - img = img.resize((int(np.floor(new_width)), size), pil.ANTIALIAS) - + img = img.resize((int(np.floor(new_width)), size)) elif old_width > old_height: ratio = float(old_height) / float(old_width) new_height = ratio * size - img = img.resize((size, int(np.floor(new_height))), pil.ANTIALIAS) + img = img.resize((size, int(np.floor(new_height)))) return img diff --git a/pynxtools/definitions b/pynxtools/definitions index 4188634b2..400ac9bdd 160000 --- a/pynxtools/definitions +++ b/pynxtools/definitions @@ -1 +1 @@ -Subproject commit 4188634b21a6f5c4491e964412c70df63e495b54 +Subproject commit 400ac9bddd7aa0907bc18f610e5c1dec7087fb16 From ea780891ca53cf9c58cdb6c590c3978dd09dfb6d Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Thu, 20 Jul 2023 14:07:22 +0200 Subject: [PATCH 09/18] Updated README to guide users as to how they can install jupyter and related h5web to run standalone examples --- README.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/README.md b/README.md index b034fddb7..eb351d9d6 100644 --- a/README.md +++ b/README.md @@ -71,6 +71,18 @@ Especially relevant for developers, there exists a basic test framework written python -m pytest -sv tests ``` +## Run examples + +A number of examples exist which document how the tools can be used. For a standalone +usage convenient jupyter notebooks are available for each tool. To use them jupyter +and related tools have to be installed in the development environment as follows: + +```shell +python -m pip install jupyter +python -m pip install jupyterlab +python -m pip install jupyterlab_h5web +``` + # Questions, suggestions? To ask further questions, to make suggestions how we can improve these tools, to get advice From fdccf196b9f8aa6faa12a887b31b13e69b3d7ae7 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Thu, 20 Jul 2023 14:42:51 +0200 Subject: [PATCH 10/18] Fixed failing NXiv_temp test caused by def changes, NXmpes and NXarpes are also affected as many fields in base classes were removed in during the code camp, please inspect @domna, updated dev-requirements and, fixed linting --- dev-requirements.txt | 188 +----------------- .../readers/em_om/utils/image_transform.py | 1 - tests/nexus/test_nexus.py | 2 +- 3 files changed, 11 insertions(+), 180 deletions(-) diff --git a/dev-requirements.txt b/dev-requirements.txt index 0620dae14..8201e8a12 100644 --- a/dev-requirements.txt +++ b/dev-requirements.txt @@ -1,20 +1,11 @@ # -# This file is autogenerated by pip-compile with Python 3.10 +# This file is autogenerated by pip-compile with Python 3.9 # by the following command: # # pip-compile --extra=dev --output-file=dev-requirements.txt --resolver=backtracking pyproject.toml # -anyio==3.6.1 - # via jupyter-server appdirs==1.4.4 # via requests-cache -argon2-cffi==21.3.0 - # via - # jupyter-server - # nbclassic - # notebook -argon2-cffi-bindings==21.2.0 - # via argon2-cffi asciitree==0.3.3 # via zarr ase==3.19.0 @@ -28,25 +19,16 @@ astroid==2.12.10 attrs==22.1.0 # via # cattrs - # jsonschema # pytest # requests-cache -babel==2.11.0 - # via jupyterlab-server backcall==0.2.0 # via ipython -beautifulsoup4==4.11.1 - # via nbconvert -bleach==5.0.1 - # via nbconvert build==0.10.0 # via pip-tools cattrs==22.2.0 # via requests-cache certifi==2022.9.24 # via requests -cffi==1.15.1 - # via argon2-cffi-bindings charset-normalizer==2.1.1 # via requests click==8.1.3 @@ -71,8 +53,6 @@ decorator==5.1.1 # via # ipyparallel # ipython -defusedxml==0.7.1 - # via nbconvert diffpy-structure==3.1.0 # via # diffsims @@ -99,8 +79,6 @@ fabio==2023.4.1 # silx fasteners==0.18 # via zarr -fastjsonschema==2.16.2 - # via nbformat flatdict==4.0.1 # via pynxtools (pyproject.toml) fonttools==4.37.4 @@ -115,14 +93,10 @@ gitdb==4.0.10 # via gitpython gitpython==3.1.30 # via pynxtools (pyproject.toml) -h5grove==1.2.0 - # via jupyterlab-h5web h5py==3.7.0 # via - # h5grove # hyperspy # ifes-apt-tc-data-modeling - # jupyterlab-h5web # kikuchipy # nionswift # orix @@ -135,10 +109,8 @@ hyperspy==1.7.4 # pynxtools (pyproject.toml) # pyxem idna==3.4 - # via - # anyio - # requests -ifes-apt-tc-data-modeling==0.0.8 + # via requests +ifes-apt-tc-data-modeling==0.0.9 # via pynxtools (pyproject.toml) imageio==2.22.1 # via @@ -156,8 +128,6 @@ ipykernel==6.16.0 # via # ipyparallel # ipywidgets - # nbclassic - # notebook ipyparallel==8.4.1 # via hyperspy ipython==7.34.0 @@ -166,11 +136,6 @@ ipython==7.34.0 # ipykernel # ipyparallel # ipywidgets - # jupyterlab -ipython-genutils==0.2.0 - # via - # nbclassic - # notebook ipywidgets==8.0.6 # via pyxem isort==5.10.1 @@ -178,58 +143,15 @@ isort==5.10.1 jedi==0.18.1 # via ipython jinja2==3.1.2 - # via - # hyperspy - # jupyter-server - # jupyterlab - # jupyterlab-server - # nbclassic - # nbconvert - # notebook + # via hyperspy joblib==1.2.0 # via scikit-learn -json5==0.9.11 - # via jupyterlab-server -jsonschema==4.17.3 - # via - # jupyterlab-server - # nbformat jupyter-client==7.3.5 # via # ipykernel # ipyparallel - # jupyter-server - # nbclassic - # nbclient - # notebook jupyter-core==5.1.5 - # via - # jupyter-client - # jupyter-server - # jupyterlab - # nbclassic - # nbconvert - # nbformat - # notebook -jupyter-server==1.23.5 - # via - # jupyterlab - # jupyterlab-h5web - # jupyterlab-server - # nbclassic - # notebook-shim -jupyterlab==3.5.3 - # via - # ifes-apt-tc-data-modeling - # pynxtools (pyproject.toml) -jupyterlab-h5web==7.0.0 - # via - # ifes-apt-tc-data-modeling - # pynxtools (pyproject.toml) -jupyterlab-pygments==0.2.2 - # via nbconvert -jupyterlab-server==2.19.0 - # via jupyterlab + # via jupyter-client jupyterlab-widgets==3.0.7 # via ipywidgets kikuchipy==0.8.4 @@ -247,9 +169,7 @@ lmfit==1.2.0 locket==1.0.0 # via partd markupsafe==2.1.1 - # via - # jinja2 - # nbconvert + # via jinja2 matplotlib==3.5.3 # via # ase @@ -269,8 +189,6 @@ matplotlib-scalebar==0.8.1 # via orix mccabe==0.7.0 # via pylint -mistune==2.0.4 - # via nbconvert mpmath==1.2.1 # via sympy mypy==0.982 @@ -279,31 +197,10 @@ mypy-extensions==0.4.3 # via mypy natsort==8.2.0 # via hyperspy -nbclassic==0.4.8 - # via - # jupyterlab - # notebook -nbclient==0.6.8 - # via nbconvert -nbconvert==7.1.0 - # via - # jupyter-server - # nbclassic - # notebook -nbformat==5.6.1 - # via - # jupyter-server - # nbclassic - # nbclient - # nbconvert - # notebook nest-asyncio==1.5.6 # via # ipykernel # jupyter-client - # nbclassic - # nbclient - # notebook networkx==2.6.3 # via # radioactivedecay @@ -324,10 +221,6 @@ nionutils==0.4.6 # nionswift # nionswift-io # nionui -notebook==6.5.2 - # via jupyterlab -notebook-shim==0.2.2 - # via nbclassic numba==0.56.2 # via # diffsims @@ -348,7 +241,6 @@ numpy==1.21.6 # dask # diffsims # fabio - # h5grove # h5py # hyperspy # ifes-apt-tc-data-modeling @@ -386,19 +278,13 @@ orix==0.11.1 # diffsims # kikuchipy # pyxem -orjson==3.8.0 - # via h5grove packaging==21.3 # via # build # dask # hyperspy # ipykernel - # jupyter-server - # jupyterlab - # jupyterlab-server # matplotlib - # nbconvert # numexpr # pint # pooch @@ -409,8 +295,6 @@ pandas==1.3.5 # ifes-apt-tc-data-modeling # pynxtools (pyproject.toml) # xarray -pandocfilters==1.5.0 - # via nbconvert parso==0.8.3 # via jedi partd==1.3.0 @@ -442,11 +326,6 @@ pooch==1.7.0 # orix prettytable==3.4.1 # via hyperspy -prometheus-client==0.14.1 - # via - # jupyter-server - # nbclassic - # notebook prompt-toolkit==3.0.31 # via ipython psutil==5.9.2 @@ -456,23 +335,17 @@ psutil==5.9.2 # ipyparallel # pyxem ptyprocess==0.7.0 - # via - # pexpect - # terminado + # via pexpect py==1.11.0 # via pytest pycifrw==4.4.5 # via diffpy-structure pycodestyle==2.9.1 # via pynxtools (pyproject.toml) -pycparser==2.21 - # via cffi pyfai==2023.3.0 # via pyxem pygments==2.13.0 - # via - # ipython - # nbconvert + # via ipython pylint==2.15.3 # via pynxtools (pyproject.toml) pyparsing==3.0.9 @@ -481,8 +354,6 @@ pyparsing==3.0.9 # packaging pyproject-hooks==1.0.0 # via build -pyrsistent==0.18.1 - # via jsonschema pytest==7.1.3 # via # pynxtools (pyproject.toml) @@ -501,7 +372,6 @@ python-dateutil==2.8.2 # pandas pytz==2022.4 # via - # babel # nionswift # pandas # pynxtools (pyproject.toml) @@ -522,15 +392,11 @@ pyzmq==24.0.1 # ipykernel # ipyparallel # jupyter-client - # jupyter-server - # nbclassic - # notebook radioactivedecay==0.4.16 # via ifes-apt-tc-data-modeling requests==2.28.1 # via # hyperspy - # jupyterlab-server # pooch # pynxtools (pyproject.toml) # requests-cache @@ -562,25 +428,15 @@ scipy==1.7.3 # scikit-image # scikit-learn # sparse -send2trash==1.8.0 - # via - # jupyter-server - # nbclassic - # notebook silx==1.1.2 # via pyfai six==1.16.0 # via - # bleach # diffpy-structure # python-dateutil # url-normalize smmap==5.0.0 # via gitdb -sniffio==1.3.0 - # via anyio -soupsieve==2.3.2.post1 - # via beautifulsoup4 sparse==0.13.0 # via hyperspy structlog==22.1.0 @@ -589,25 +445,16 @@ sympy==1.10.1 # via # hyperspy # radioactivedecay -terminado==0.16.0 - # via - # jupyter-server - # nbclassic - # notebook threadpoolctl==3.1.0 # via scikit-learn tifffile==2021.11.2 # via - # h5grove # hyperspy # scikit-image -tinycss2==1.1.1 - # via nbconvert tomli==2.0.1 # via # build # coverage - # jupyterlab # mypy # pylint # pyproject-hooks @@ -624,11 +471,6 @@ tornado==6.2 # ipykernel # ipyparallel # jupyter-client - # jupyter-server - # jupyterlab - # nbclassic - # notebook - # terminado tqdm==4.64.1 # via # diffsims @@ -644,13 +486,7 @@ traitlets==5.4.0 # ipywidgets # jupyter-client # jupyter-core - # jupyter-server # matplotlib-inline - # nbclassic - # nbclient - # nbconvert - # nbformat - # notebook traits==6.4.1 # via hyperspy transforms3d==0.4.1 @@ -667,8 +503,10 @@ types-urllib3==1.26.25.5 # via types-requests typing-extensions==4.3.0 # via + # astroid # mypy # numcodecs + # pylint tzdata==2023.3 # via pytz-deprecation-shim tzlocal==4.3 @@ -687,12 +525,6 @@ wcwidth==0.2.5 # via # prettytable # prompt-toolkit -webencodings==0.5.1 - # via - # bleach - # tinycss2 -websocket-client==1.4.1 - # via jupyter-server wheel==0.40.0 # via pip-tools widgetsnbextension==4.0.7 diff --git a/pynxtools/dataconverter/readers/em_om/utils/image_transform.py b/pynxtools/dataconverter/readers/em_om/utils/image_transform.py index 8a11afc77..7369ebef8 100644 --- a/pynxtools/dataconverter/readers/em_om/utils/image_transform.py +++ b/pynxtools/dataconverter/readers/em_om/utils/image_transform.py @@ -23,7 +23,6 @@ # f" how-do-i-make-pil-take-into-account-the-shortest-side-when-creating-a-thumbnail" import numpy as np -from PIL import Image as pil def thumbnail(img, size=300): diff --git a/tests/nexus/test_nexus.py b/tests/nexus/test_nexus.py index 5011fe2ce..894657d7a 100644 --- a/tests/nexus/test_nexus.py +++ b/tests/nexus/test_nexus.py @@ -169,7 +169,7 @@ def test_get_inherited_nodes(): (_, _, elist) = nexus.get_inherited_nodes( nxdl_path="/ENTRY/INSTRUMENT/ENVIRONMENT", elem=elem) - assert len(elist) == 4 + assert len(elist) == 3 (_, _, elist) = nexus.get_inherited_nodes( nxdl_path="/ENTRY/INSTRUMENT/ENVIRONMENT/voltage_controller", From 65405b5e0edced2c4e5cd34ba435993a73ae3886 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Thu, 20 Jul 2023 15:43:10 +0200 Subject: [PATCH 11/18] Attempt fixing pytests, was successful for Ref_nexus_mpes but not for Ref_nexus_test, this commit might therefore need to be reverted --- .../readers/mpes/Ref_nexus_mpes.log | 1613 +++++------------ tests/data/nexus/Ref_nexus_test.log | 691 +++---- 2 files changed, 710 insertions(+), 1594 deletions(-) diff --git a/tests/data/dataconverter/readers/mpes/Ref_nexus_mpes.log b/tests/data/dataconverter/readers/mpes/Ref_nexus_mpes.log index 46413f676..35c7fb42f 100644 --- a/tests/data/dataconverter/readers/mpes/Ref_nexus_mpes.log +++ b/tests/data/dataconverter/readers/mpes/Ref_nexus_mpes.log @@ -8,13 +8,12 @@ DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY): DEBUG - DEBUG - documentation (NXentry.nxdl.xml:): DEBUG - - (**required**) :ref:`NXentry` describes the measurement. - - The top-level NeXus group which contains all the data and associated - information that comprise a single measurement. - It is mandatory that there is at least one - group of this type in the NeXus file. - + (**required**) :ref:`NXentry` describes the measurement. + + The top-level NeXus group which contains all the data and associated + information that comprise a single measurement. + It is mandatory that there is at least one + group of this type in the NeXus file. DEBUG - ===== ATTRS (//entry@NX_class) DEBUG - value: NXentry DEBUG - classpath: ['NXentry'] @@ -33,23 +32,23 @@ DEBUG - NXmpes.nxdl.xml:/ENTRY@default - [NX_CHAR] DEBUG - NXentry.nxdl.xml:@default - [NX_CHAR] DEBUG - documentation (NXentry.nxdl.xml:/default): DEBUG - - .. index:: find the default plottable data - .. index:: plotting - .. index:: default attribute value - - Declares which :ref:`NXdata` group contains the data - to be shown by default. - It is used to resolve ambiguity when - one :ref:`NXdata` group exists. - The value :ref:`names ` a child group. If that group - itself has a ``default`` attribute, continue this chain until an - :ref:`NXdata` group is reached. - - For more information about how NeXus identifies the default - plottable data, see the - :ref:`Find Plottable Data, v3 ` - section. - + .. index:: find the default plottable data + .. index:: plotting + .. index:: default attribute value + + Declares which :ref:`NXdata` group contains the data + to be shown by default. + It is used to resolve ambiguity when + one :ref:`NXdata` group exists. + The value :ref:`names ` a child group. If that group + itself has a ``default`` attribute, continue this chain until an + :ref:`NXdata` group is reached. + + For more information about how NeXus identifies the default + plottable data, see the + :ref:`Find Plottable Data, v3 ` + section. + DEBUG - ===== FIELD (//entry/collection_time): DEBUG - value: 2317.343 DEBUG - classpath: ['NXentry', 'NX_FLOAT'] @@ -58,9 +57,9 @@ NXentry.nxdl.xml:/collection_time DEBUG - <> DEBUG - documentation (NXentry.nxdl.xml:/collection_time): DEBUG - - Time transpired actually collecting data i.e. taking out time when collection was - suspended due to e.g. temperature out of range - + Time transpired actually collecting data i.e. taking out time when collection was + suspended due to e.g. temperature out of range + DEBUG - ===== ATTRS (//entry/collection_time@units) DEBUG - value: s DEBUG - classpath: ['NXentry', 'NX_FLOAT'] @@ -78,33 +77,34 @@ DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/DATA): DEBUG - DEBUG - documentation (NXentry.nxdl.xml:/DATA): DEBUG - - The data group - - .. note:: Before the NIAC2016 meeting [#]_, at least one - :ref:`NXdata` group was required in each :ref:`NXentry` group. - At the NIAC2016 meeting, it was decided to make :ref:`NXdata` - an optional group in :ref:`NXentry` groups for data files that - do not use an application definition. - It is recommended strongly that all NeXus data files provide - a NXdata group. - It is permissable to omit the NXdata group only when - defining the default plot is not practical or possible - from the available data. - - For example, neutron event data may not have anything that - makes a useful plot without extensive processing. - - Certain application definitions override this decision and - require an :ref:`NXdata` group - in the :ref:`NXentry` group. The ``minOccurs=0`` attribute - in the application definition will indicate the - :ref:`NXdata` group - is optional, otherwise, it is required. - - .. [#] NIAC2016: - https://www.nexusformat.org/NIAC2016.html, - https://github.com/nexusformat/NIAC/issues/16 - + The data group + + .. note:: Before the NIAC2016 meeting [#]_, at least one + :ref:`NXdata` group was required in each :ref:`NXentry` group. + At the NIAC2016 meeting, it was decided to make :ref:`NXdata` + an optional group in :ref:`NXentry` groups for data files that + do not use an application definition. + It is recommended strongly that all NeXus data files provide + a NXdata group. + It is permissable to omit the NXdata group only when + defining the default plot is not practical or possible + from the available data. + + For example, neutron event data may not have anything that + makes a useful plot without extensive processing. + + Certain application definitions override this decision and + require an :ref:`NXdata` group + in the :ref:`NXentry` group. The ``minOccurs=0`` attribute + in the application definition will indicate the + :ref:`NXdata` group + is optional, otherwise, it is required. + + .. [#] NIAC2016: + https://www.nexusformat.org/NIAC2016.html, + https://github.com/nexusformat/NIAC/issues/16 + + DEBUG - documentation (NXdata.nxdl.xml:): DEBUG - :ref:`NXdata` describes the plottable data and related dimension scales. @@ -466,21 +466,21 @@ DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/definition): DEBUG - DEBUG - documentation (NXentry.nxdl.xml:/definition): DEBUG - - (alternate use: see same field in :ref:`NXsubentry` for preferred) - - Official NeXus NXDL schema to which this entry conforms which must be - the name of the NXDL file (case sensitive without the file extension) - that the NXDL schema is defined in. - - For example the ``definition`` field for a file that conformed to the - *NXarpes.nxdl.xml* definition must contain the string **NXarpes**. - - This field is provided so that :ref:`NXentry` can be the overlay position - in a NeXus data file for an application definition and its - set of groups, fields, and attributes. - - *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. - + (alternate use: see same field in :ref:`NXsubentry` for preferred) + + Official NeXus NXDL schema to which this entry conforms which must be + the name of the NXDL file (case sensitive without the file extension) + that the NXDL schema is defined in. + + For example the ``definition`` field for a file that conformed to the + *NXarpes.nxdl.xml* definition must contain the string **NXarpes**. + + This field is provided so that :ref:`NXentry` can be the overlay position + in a NeXus data file for an application definition and its + set of groups, fields, and attributes. + + *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. + DEBUG - ===== ATTRS (//entry/definition@version) DEBUG - value: None DEBUG - classpath: ['NXentry', 'NX_CHAR'] @@ -493,9 +493,7 @@ DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/definition/version): DEBUG - DEBUG - NXentry.nxdl.xml:/definition@version - [NX_CHAR] DEBUG - documentation (NXentry.nxdl.xml:/definition/version): -DEBUG - - NXDL version number - +DEBUG - NXDL version number DEBUG - ===== FIELD (//entry/duration): DEBUG - value: 2317 DEBUG - classpath: ['NXentry', 'NX_INT'] @@ -503,9 +501,7 @@ DEBUG - classes: NXentry.nxdl.xml:/duration DEBUG - <> DEBUG - documentation (NXentry.nxdl.xml:/duration): -DEBUG - - Duration of measurement - +DEBUG - Duration of measurement DEBUG - ===== ATTRS (//entry/duration@units) DEBUG - value: s DEBUG - classpath: ['NXentry', 'NX_INT'] @@ -519,9 +515,7 @@ DEBUG - classes: NXentry.nxdl.xml:/end_time DEBUG - <> DEBUG - documentation (NXentry.nxdl.xml:/end_time): -DEBUG - - Ending time of measurement - +DEBUG - Ending time of measurement DEBUG - ===== FIELD (//entry/entry_identifier): DEBUG - value: b'2019/2019_05/2019_05_23/Scan005' DEBUG - classpath: ['NXentry', 'NX_CHAR'] @@ -529,39 +523,22 @@ DEBUG - classes: NXentry.nxdl.xml:/entry_identifier DEBUG - <> DEBUG - documentation (NXentry.nxdl.xml:/entry_identifier): -DEBUG - - Unique identifier for the measurement, defined by the facility. - +DEBUG - unique identifier for the measurement, defined by the facility. DEBUG - ===== FIELD (//entry/experiment_facility): DEBUG - value: b'Time Resolved ARPES' -DEBUG - classpath: ['NXentry', 'NX_CHAR'] -DEBUG - classes: -NXentry.nxdl.xml:/experiment_facility -DEBUG - <> -DEBUG - documentation (NXentry.nxdl.xml:/experiment_facility): +DEBUG - classpath: ['NXentry'] +DEBUG - NOT IN SCHEMA DEBUG - - Name of the experimental facility - DEBUG - ===== FIELD (//entry/experiment_institution): DEBUG - value: b'Fritz Haber Institute - Max Planck Society' -DEBUG - classpath: ['NXentry', 'NX_CHAR'] -DEBUG - classes: -NXentry.nxdl.xml:/experiment_institution -DEBUG - <> -DEBUG - documentation (NXentry.nxdl.xml:/experiment_institution): +DEBUG - classpath: ['NXentry'] +DEBUG - NOT IN SCHEMA DEBUG - - Name of the institution hosting the facility - DEBUG - ===== FIELD (//entry/experiment_laboratory): DEBUG - value: b'Clean Room 4' -DEBUG - classpath: ['NXentry', 'NX_CHAR'] -DEBUG - classes: -NXentry.nxdl.xml:/experiment_laboratory -DEBUG - <> -DEBUG - documentation (NXentry.nxdl.xml:/experiment_laboratory): +DEBUG - classpath: ['NXentry'] +DEBUG - NOT IN SCHEMA DEBUG - - Name of the laboratory or beamline - DEBUG - ===== GROUP (//entry/instrument [NXmpes::/NXentry/NXinstrument]): DEBUG - classpath: ['NXentry', 'NXinstrument'] DEBUG - classes: @@ -575,15 +552,15 @@ DEBUG - documentation (NXentry.nxdl.xml:/INSTRUMENT): DEBUG - DEBUG - documentation (NXinstrument.nxdl.xml:): DEBUG - - Collection of the components of the instrument or beamline. - - Template of instrument descriptions comprising various beamline components. - Each component will also be a NeXus group defined by its distance from the - sample. Negative distances represent beamline components that are before the - sample while positive distances represent components that are after the sample. - This device allows the unique identification of beamline components in a way - that is valid for both reactor and pulsed instrumentation. - + Collection of the components of the instrument or beamline. + + Template of instrument descriptions comprising various beamline components. + Each component will also be a NeXus group defined by its distance from the + sample. Negative distances represent beamline components that are before the + sample while positive distances represent components that are after the sample. + This device allows the unique identification of beamline components in a way + that is valid for both reactor and pulsed instrumentation. + DEBUG - ===== ATTRS (//entry/instrument@NX_class) DEBUG - value: NXinstrument DEBUG - classpath: ['NXentry', 'NXinstrument'] @@ -606,19 +583,22 @@ DEBUG - documentation (NXinstrument.nxdl.xml:/BEAM): DEBUG - DEBUG - documentation (NXbeam.nxdl.xml:): DEBUG - - Properties of the neutron or X-ray beam at a given location. - - This group is intended to be referenced - by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. This group is - especially valuable in storing the results of instrument simulations in which it is useful - to specify the beam profile, time distribution etc. at each beamline component. Otherwise, - its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron - scattering by the sample, e.g., energy transfer, polarizations. - - Note that incident_wavelength and related fields can be a scalar values or arrays, depending on the use case. - To support these use cases, the explicit dimensionality of these fields is not specified, but it can be inferred - by the presense of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam. - + Properties of the neutron or X-ray beam at a given location. + + This group is intended to be referenced + by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. This group is + especially valuable in storing the results of instrument simulations in which it is useful + to specify the beam profile, time distribution etc. at each beamline component. Otherwise, + its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron + scattering by the sample, e.g., energy transfer, polarizations. Finally, There are cases where the beam is + considered as a beamline component and this group may be defined as a subgroup directly inside + :ref:`NXinstrument`, in which case it is recommended that the position of the beam is specified by an + :ref:`NXtransformations` group, unless the beam is at the origin (which is the sample). + + Note that incident_wavelength and related fields can be a scalar values or arrays, depending on the use case. + To support these use cases, the explicit dimensionality of these fields is not specified, but it can be inferred + by the presense of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam. + DEBUG - ===== ATTRS (//entry/instrument/beam@NX_class) DEBUG - value: NXbeam DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] @@ -652,8 +632,8 @@ NXbeam.nxdl.xml:/extent DEBUG - <> DEBUG - documentation (NXbeam.nxdl.xml:/extent): DEBUG - - Size of the beam entering this component. Note this represents - a rectangular beam aperture, and values represent FWHM + Size of the beam entering this component. Note this represents + a rectangular beam aperture, and values represent FWHM DEBUG - ===== ATTRS (//entry/instrument/beam/extent@units) DEBUG - value: µm @@ -671,24 +651,7 @@ DEBUG - <> DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy): DEBUG - DEBUG - documentation (NXbeam.nxdl.xml:/incident_energy): -DEBUG - - 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. - +DEBUG - Energy carried by each particle of the beam on entering the beamline component DEBUG - ===== ATTRS (//entry/instrument/beam/incident_energy@units) DEBUG - value: eV DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] @@ -702,25 +665,15 @@ DEBUG - value: 0.11 DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] DEBUG - classes: NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy_spread -NXbeam.nxdl.xml:/incident_energy_spread DEBUG - <> DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy_spread): DEBUG - -DEBUG - documentation (NXbeam.nxdl.xml:/incident_energy_spread): -DEBUG - - 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. - DEBUG - ===== ATTRS (//entry/instrument/beam/incident_energy_spread@units) DEBUG - value: eV DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] DEBUG - classes: NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy_spread -NXbeam.nxdl.xml:/incident_energy_spread DEBUG - NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy_spread@units [NX_ENERGY] -DEBUG - NXbeam.nxdl.xml:/incident_energy_spread@units [NX_ENERGY] DEBUG - ===== FIELD (//entry/instrument/beam/incident_polarization): DEBUG - value: [1. 1. 0. 0.] DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] @@ -731,10 +684,7 @@ DEBUG - <> DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_polarization): DEBUG - DEBUG - documentation (NXbeam.nxdl.xml:/incident_polarization): -DEBUG - - Incident polarization as a Stokes vector - on entering beamline component - +DEBUG - Polarization vector on entering beamline component DEBUG - ===== ATTRS (//entry/instrument/beam/incident_polarization@units) DEBUG - value: V^2/mm^2 DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] @@ -745,20 +695,14 @@ DEBUG - NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_polarization@units [NX_A DEBUG - NXbeam.nxdl.xml:/incident_polarization@units [NX_ANY] DEBUG - ===== FIELD (//entry/instrument/beam/pulse_duration): DEBUG - value: 20.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/pulse_duration -DEBUG - <> -DEBUG - documentation (NXbeam.nxdl.xml:/pulse_duration): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] +DEBUG - NOT IN SCHEMA DEBUG - - FWHM duration of the pulses at the diagnostic point - DEBUG - ===== ATTRS (//entry/instrument/beam/pulse_duration@units) DEBUG - value: fs -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/pulse_duration -DEBUG - NXbeam.nxdl.xml:/pulse_duration@units [NX_TIME] +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== GROUP (//entry/instrument/beam_pump [NXmpes::/NXentry/NXinstrument/NXbeam]): DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] DEBUG - classes: @@ -772,19 +716,22 @@ DEBUG - documentation (NXinstrument.nxdl.xml:/BEAM): DEBUG - DEBUG - documentation (NXbeam.nxdl.xml:): DEBUG - - Properties of the neutron or X-ray beam at a given location. - - This group is intended to be referenced - by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. This group is - especially valuable in storing the results of instrument simulations in which it is useful - to specify the beam profile, time distribution etc. at each beamline component. Otherwise, - its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron - scattering by the sample, e.g., energy transfer, polarizations. - - Note that incident_wavelength and related fields can be a scalar values or arrays, depending on the use case. - To support these use cases, the explicit dimensionality of these fields is not specified, but it can be inferred - by the presense of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam. - + Properties of the neutron or X-ray beam at a given location. + + This group is intended to be referenced + by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. This group is + especially valuable in storing the results of instrument simulations in which it is useful + to specify the beam profile, time distribution etc. at each beamline component. Otherwise, + its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron + scattering by the sample, e.g., energy transfer, polarizations. Finally, There are cases where the beam is + considered as a beamline component and this group may be defined as a subgroup directly inside + :ref:`NXinstrument`, in which case it is recommended that the position of the beam is specified by an + :ref:`NXtransformations` group, unless the beam is at the origin (which is the sample). + + Note that incident_wavelength and related fields can be a scalar values or arrays, depending on the use case. + To support these use cases, the explicit dimensionality of these fields is not specified, but it can be inferred + by the presense of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam. + DEBUG - ===== ATTRS (//entry/instrument/beam_pump@NX_class) DEBUG - value: NXbeam DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] @@ -796,20 +743,14 @@ DEBUG - @NX_class [NX_CHAR] DEBUG - DEBUG - ===== FIELD (//entry/instrument/beam_pump/average_power): DEBUG - value: 444.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/average_power -DEBUG - <> -DEBUG - documentation (NXbeam.nxdl.xml:/average_power): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] +DEBUG - NOT IN SCHEMA DEBUG - - Average power at the diagnostic point - DEBUG - ===== ATTRS (//entry/instrument/beam_pump/average_power@units) DEBUG - value: mW -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/average_power -DEBUG - NXbeam.nxdl.xml:/average_power@units [NX_POWER] +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/instrument/beam_pump/distance): DEBUG - value: 0.0 DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] @@ -834,8 +775,8 @@ NXbeam.nxdl.xml:/extent DEBUG - <> DEBUG - documentation (NXbeam.nxdl.xml:/extent): DEBUG - - Size of the beam entering this component. Note this represents - a rectangular beam aperture, and values represent FWHM + Size of the beam entering this component. Note this represents + a rectangular beam aperture, and values represent FWHM DEBUG - ===== ATTRS (//entry/instrument/beam_pump/extent@units) DEBUG - value: µm @@ -845,20 +786,14 @@ NXbeam.nxdl.xml:/extent DEBUG - NXbeam.nxdl.xml:/extent@units [NX_LENGTH] DEBUG - ===== FIELD (//entry/instrument/beam_pump/fluence): DEBUG - value: 1.3 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/fluence -DEBUG - <> -DEBUG - documentation (NXbeam.nxdl.xml:/fluence): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] +DEBUG - NOT IN SCHEMA DEBUG - - Incident fluence at the diagnostic point - DEBUG - ===== ATTRS (//entry/instrument/beam_pump/fluence@units) DEBUG - value: mJ/cm^2 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/fluence -DEBUG - NXbeam.nxdl.xml:/fluence@units [NX_ANY] +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/instrument/beam_pump/incident_energy): DEBUG - value: 1.2 DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] @@ -869,24 +804,7 @@ DEBUG - <> DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy): DEBUG - DEBUG - documentation (NXbeam.nxdl.xml:/incident_energy): -DEBUG - - 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. - +DEBUG - Energy carried by each particle of the beam on entering the beamline component DEBUG - ===== ATTRS (//entry/instrument/beam_pump/incident_energy@units) DEBUG - value: eV DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] @@ -900,25 +818,15 @@ DEBUG - value: 0.05 DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] DEBUG - classes: NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy_spread -NXbeam.nxdl.xml:/incident_energy_spread DEBUG - <> DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy_spread): DEBUG - -DEBUG - documentation (NXbeam.nxdl.xml:/incident_energy_spread): -DEBUG - - 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. - DEBUG - ===== ATTRS (//entry/instrument/beam_pump/incident_energy_spread@units) DEBUG - value: eV DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] DEBUG - classes: NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy_spread -NXbeam.nxdl.xml:/incident_energy_spread DEBUG - NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy_spread@units [NX_ENERGY] -DEBUG - NXbeam.nxdl.xml:/incident_energy_spread@units [NX_ENERGY] DEBUG - ===== FIELD (//entry/instrument/beam_pump/incident_polarization): DEBUG - value: [1 1 0 0] DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] @@ -929,10 +837,7 @@ DEBUG - <> DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_polarization): DEBUG - DEBUG - documentation (NXbeam.nxdl.xml:/incident_polarization): -DEBUG - - Incident polarization as a Stokes vector - on entering beamline component - +DEBUG - Polarization vector on entering beamline component DEBUG - ===== ATTRS (//entry/instrument/beam_pump/incident_polarization@units) DEBUG - value: V^2/mm^2 DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] @@ -949,38 +854,38 @@ NXbeam.nxdl.xml:/incident_wavelength DEBUG - <> DEBUG - documentation (NXbeam.nxdl.xml:/incident_wavelength): DEBUG - - In the case of a monochromatic beam this is the scalar - wavelength. - - Several other use cases are permitted, depending on the - presence or absence of other incident_wavelength_X - fields. - - In the case of a polychromatic beam this is an array of - length **m** of wavelengths, with the relative weights - in ``incident_wavelength_weights``. - - In the case of a monochromatic beam that varies shot- - to-shot, this is an array of wavelengths, one for each - recorded shot. Here, ``incident_wavelength_weights`` and - incident_wavelength_spread are not set. - - In the case of a polychromatic beam that varies shot-to- - shot, this is an array of length **m** with the relative - weights in ``incident_wavelength_weights`` as a 2D array. - - In the case of a polychromatic beam that varies shot-to- - shot and where the channels also vary, this is a 2D array - of dimensions **nP** by **m** (slow to fast) with the - relative weights in ``incident_wavelength_weights`` as a 2D - array. - - Note, :ref:`variants ` are a good way - to represent several of these use cases in a single dataset, - e.g. if a calibrated, single-value wavelength value is - available along with the original spectrum from which it - was calibrated. - Wavelength on entering beamline component + In the case of a monochromatic beam this is the scalar + wavelength. + + Several other use cases are permitted, depending on the + presence or absence of other incident_wavelength_X + fields. + + In the case of a polychromatic beam this is an array of + length **m** of wavelengths, with the relative weights + in ``incident_wavelength_weights``. + + In the case of a monochromatic beam that varies shot- + to-shot, this is an array of wavelengths, one for each + recorded shot. Here, ``incident_wavelength_weights`` and + incident_wavelength_spread are not set. + + In the case of a polychromatic beam that varies shot-to- + shot, this is an array of length **m** with the relative + weights in ``incident_wavelength_weights`` as a 2D array. + + In the case of a polychromatic beam that varies shot-to- + shot and where the channels also vary, this is a 2D array + of dimensions **nP** by **m** (slow to fast) with the + relative weights in ``incident_wavelength_weights`` as a 2D + array. + + Note, :ref:`variants ` are a good way + to represent several of these use cases in a single dataset, + e.g. if a calibrated, single-value wavelength value is + available along with the original spectrum from which it + was calibrated. + Wavelength on entering beamline component DEBUG - ===== ATTRS (//entry/instrument/beam_pump/incident_wavelength@units) DEBUG - value: nm @@ -990,36 +895,24 @@ NXbeam.nxdl.xml:/incident_wavelength DEBUG - NXbeam.nxdl.xml:/incident_wavelength@units [NX_WAVELENGTH] DEBUG - ===== FIELD (//entry/instrument/beam_pump/pulse_duration): DEBUG - value: 140.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/pulse_duration -DEBUG - <> -DEBUG - documentation (NXbeam.nxdl.xml:/pulse_duration): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] +DEBUG - NOT IN SCHEMA DEBUG - - FWHM duration of the pulses at the diagnostic point - DEBUG - ===== ATTRS (//entry/instrument/beam_pump/pulse_duration@units) DEBUG - value: fs -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/pulse_duration -DEBUG - NXbeam.nxdl.xml:/pulse_duration@units [NX_TIME] +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/instrument/beam_pump/pulse_energy): DEBUG - value: 0.889 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/pulse_energy -DEBUG - <> -DEBUG - documentation (NXbeam.nxdl.xml:/pulse_energy): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] +DEBUG - NOT IN SCHEMA DEBUG - - Energy of a single pulse at the diagnostic point - DEBUG - ===== ATTRS (//entry/instrument/beam_pump/pulse_energy@units) DEBUG - value: µJ -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/pulse_energy -DEBUG - NXbeam.nxdl.xml:/pulse_energy@units [NX_ENERGY] +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== GROUP (//entry/instrument/electronanalyser [NXmpes::/NXentry/NXinstrument/NXelectronanalyser]): DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser'] DEBUG - classes: @@ -1030,7 +923,7 @@ DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER): DEBUG - DEBUG - documentation (NXelectronanalyser.nxdl.xml:): DEBUG - - Subclass of NXinstrument to describe a photoelectron analyser. + Subclass of NXinstrument to describe a photoelectron analyser. DEBUG - ===== ATTRS (//entry/instrument/electronanalyser@NX_class) DEBUG - value: NXelectronanalyser @@ -1055,8 +948,8 @@ DEBUG - DEBUG - documentation (NXcollectioncolumn.nxdl.xml:): DEBUG - - 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. DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn@NX_class) DEBUG - value: NXcollectioncolumn @@ -1085,9 +978,7 @@ DEBUG - or contrast aperture DEBUG - documentation (NXaperture.nxdl.xml:): -DEBUG - - A beamline aperture. This group is deprecated, use NXslit instead. - +DEBUG - A beamline aperture. This group is deprecated, use NXslit instead. DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/contrast_aperture@NX_class) DEBUG - value: NXaperture DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] @@ -1097,80 +988,35 @@ NXcollectioncolumn.nxdl.xml:/APERTURE NXaperture.nxdl.xml: DEBUG - @NX_class [NX_CHAR] DEBUG - -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/contrast_aperture/ca_m3 [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXaperture/NXpositioner]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture', 'NXpositioner'] -DEBUG - classes: -NXaperture.nxdl.xml:/POSITIONER -NXpositioner.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXaperture.nxdl.xml:/POSITIONER): -DEBUG - - Stores the raw positions of aperture motors. - -DEBUG - documentation (NXpositioner.nxdl.xml:): -DEBUG - - A generic positioner such as a motor or piezo-electric transducer. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/contrast_aperture/ca_m3@NX_class) -DEBUG - value: NXpositioner -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture', 'NXpositioner'] -DEBUG - classes: -NXaperture.nxdl.xml:/POSITIONER -NXpositioner.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] +DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/contrast_aperture/ca_m3 [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXaperture/ca_m3]): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] +DEBUG - NOT IN SCHEMA DEBUG - DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/contrast_aperture/ca_m3/value): DEBUG - value: -11.49979350759219 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture', 'NXpositioner', 'NX_NUMBER'] -DEBUG - classes: -NXpositioner.nxdl.xml:/value -DEBUG - <> -DEBUG - documentation (NXpositioner.nxdl.xml:/value): -DEBUG - best known value of positioner - need [n] as may be scanned +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/contrast_aperture/ca_m3/value@units) DEBUG - value: mm -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture', 'NXpositioner', 'NX_NUMBER'] -DEBUG - classes: -NXpositioner.nxdl.xml:/value -DEBUG - NXpositioner.nxdl.xml:/value@units [NX_ANY] +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/contrast_aperture/shape): DEBUG - value: b'open' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture', 'NX_CHAR'] -DEBUG - classes: -NXaperture.nxdl.xml:/shape -DEBUG - <> -DEBUG - enumeration (NXaperture.nxdl.xml:/shape): -DEBUG - -> straight slit -DEBUG - -> curved slit -DEBUG - -> pinhole -DEBUG - -> circle -DEBUG - -> square -DEBUG - -> hexagon -DEBUG - -> octagon -DEBUG - -> bladed -DEBUG - -> open -DEBUG - -> grid -DEBUG - documentation (NXaperture.nxdl.xml:/shape): -DEBUG - - Shape of the aperture. - +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/contrast_aperture/size): DEBUG - value: nan -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture', 'NX_NUMBER'] -DEBUG - classes: -NXaperture.nxdl.xml:/size -DEBUG - <> -DEBUG - documentation (NXaperture.nxdl.xml:/size): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] +DEBUG - NOT IN SCHEMA DEBUG - - The relevant dimension for the aperture, i.e. slit width, pinhole and iris - diameter - DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/contrast_aperture/size@units) DEBUG - value: µm -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture', 'NX_NUMBER'] -DEBUG - classes: -NXaperture.nxdl.xml:/size -DEBUG - NXaperture.nxdl.xml:/size@units [NX_LENGTH] +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/extractor_current): DEBUG - value: -0.1309711275510204 DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NX_FLOAT'] @@ -1222,9 +1068,7 @@ DEBUG - or contrast aperture DEBUG - documentation (NXaperture.nxdl.xml:): -DEBUG - - A beamline aperture. This group is deprecated, use NXslit instead. - +DEBUG - A beamline aperture. This group is deprecated, use NXslit instead. DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/field_aperture@NX_class) DEBUG - value: NXaperture DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] @@ -1234,116 +1078,49 @@ NXcollectioncolumn.nxdl.xml:/APERTURE NXaperture.nxdl.xml: DEBUG - @NX_class [NX_CHAR] DEBUG - -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/fa_m1 [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXaperture/NXpositioner]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture', 'NXpositioner'] -DEBUG - classes: -NXaperture.nxdl.xml:/POSITIONER -NXpositioner.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXaperture.nxdl.xml:/POSITIONER): -DEBUG - - Stores the raw positions of aperture motors. - -DEBUG - documentation (NXpositioner.nxdl.xml:): -DEBUG - - A generic positioner such as a motor or piezo-electric transducer. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/fa_m1@NX_class) -DEBUG - value: NXpositioner -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture', 'NXpositioner'] -DEBUG - classes: -NXaperture.nxdl.xml:/POSITIONER -NXpositioner.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] +DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/fa_m1 [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXaperture/fa_m1]): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] +DEBUG - NOT IN SCHEMA DEBUG - DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/fa_m1/value): DEBUG - value: 3.749874153422982 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture', 'NXpositioner', 'NX_NUMBER'] -DEBUG - classes: -NXpositioner.nxdl.xml:/value -DEBUG - <> -DEBUG - documentation (NXpositioner.nxdl.xml:/value): -DEBUG - best known value of positioner - need [n] as may be scanned +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/fa_m1/value@units) DEBUG - value: mm -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture', 'NXpositioner', 'NX_NUMBER'] -DEBUG - classes: -NXpositioner.nxdl.xml:/value -DEBUG - NXpositioner.nxdl.xml:/value@units [NX_ANY] -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/fa_m2 [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXaperture/NXpositioner]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture', 'NXpositioner'] -DEBUG - classes: -NXaperture.nxdl.xml:/POSITIONER -NXpositioner.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXaperture.nxdl.xml:/POSITIONER): -DEBUG - - Stores the raw positions of aperture motors. - -DEBUG - documentation (NXpositioner.nxdl.xml:): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] +DEBUG - NOT IN SCHEMA DEBUG - - A generic positioner such as a motor or piezo-electric transducer. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/fa_m2@NX_class) -DEBUG - value: NXpositioner -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture', 'NXpositioner'] -DEBUG - classes: -NXaperture.nxdl.xml:/POSITIONER -NXpositioner.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] +DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/fa_m2 [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXaperture/fa_m2]): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] +DEBUG - NOT IN SCHEMA DEBUG - DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/fa_m2/value): DEBUG - value: -5.200156936301793 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture', 'NXpositioner', 'NX_NUMBER'] -DEBUG - classes: -NXpositioner.nxdl.xml:/value -DEBUG - <> -DEBUG - documentation (NXpositioner.nxdl.xml:/value): -DEBUG - best known value of positioner - need [n] as may be scanned +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/fa_m2/value@units) DEBUG - value: mm -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture', 'NXpositioner', 'NX_NUMBER'] -DEBUG - classes: -NXpositioner.nxdl.xml:/value -DEBUG - NXpositioner.nxdl.xml:/value@units [NX_ANY] +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/shape): DEBUG - value: b'circle' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture', 'NX_CHAR'] -DEBUG - classes: -NXaperture.nxdl.xml:/shape -DEBUG - <> -DEBUG - enumeration (NXaperture.nxdl.xml:/shape): -DEBUG - -> straight slit -DEBUG - -> curved slit -DEBUG - -> pinhole -DEBUG - -> circle -DEBUG - -> square -DEBUG - -> hexagon -DEBUG - -> octagon -DEBUG - -> bladed -DEBUG - -> open -DEBUG - -> grid -DEBUG - documentation (NXaperture.nxdl.xml:/shape): -DEBUG - - Shape of the aperture. - +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/size): DEBUG - value: 200.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture', 'NX_NUMBER'] -DEBUG - classes: -NXaperture.nxdl.xml:/size -DEBUG - <> -DEBUG - documentation (NXaperture.nxdl.xml:/size): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] +DEBUG - NOT IN SCHEMA DEBUG - - The relevant dimension for the aperture, i.e. slit width, pinhole and iris - diameter - DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/size@units) DEBUG - value: µm -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture', 'NX_NUMBER'] -DEBUG - classes: -NXaperture.nxdl.xml:/size -DEBUG - NXaperture.nxdl.xml:/size@units [NX_LENGTH] +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/lens_A [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXlens_em]): DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] DEBUG - classes: @@ -2135,8 +1912,8 @@ DEBUG - DEBUG - documentation (NXdetector.nxdl.xml:): DEBUG - - A detector, detector bank, or multidetector. - + A detector, detector bank, or multidetector. + DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/detector@NX_class) DEBUG - value: NXdetector DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector'] @@ -2148,26 +1925,19 @@ DEBUG - @NX_class [NX_CHAR] DEBUG - DEBUG - ===== FIELD (//entry/instrument/electronanalyser/detector/amplifier_bias): DEBUG - value: 30.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector', 'NX_FLOAT'] -DEBUG - classes: -NXdetector.nxdl.xml:/amplifier_bias -DEBUG - <> -DEBUG - documentation (NXdetector.nxdl.xml:/amplifier_bias): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector'] +DEBUG - NOT IN SCHEMA DEBUG - - The low voltage of the amplifier migh not be the ground. - DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/detector/amplifier_bias@units) DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector', 'NX_FLOAT'] -DEBUG - classes: -NXdetector.nxdl.xml:/amplifier_bias -DEBUG - NXdetector.nxdl.xml:/amplifier_bias@units [NX_VOLTAGE] +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/instrument/electronanalyser/detector/amplifier_type): DEBUG - value: b'MCP' DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector', 'NX_CHAR'] DEBUG - classes: NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/DETECTOR/amplifier_type -NXdetector.nxdl.xml:/amplifier_type DEBUG - <> DEBUG - enumeration (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/DETECTOR/amplifier_type): DEBUG - -> MCP @@ -2176,32 +1946,21 @@ DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/DETECT DEBUG - Type of electron amplifier in the first amplification step. -DEBUG - documentation (NXdetector.nxdl.xml:/amplifier_type): -DEBUG - - Type of electron amplifier, MCP, channeltron, etc. - DEBUG - ===== FIELD (//entry/instrument/electronanalyser/detector/amplifier_voltage): DEBUG - value: 2340.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector', 'NX_FLOAT'] -DEBUG - classes: -NXdetector.nxdl.xml:/amplifier_voltage -DEBUG - <> -DEBUG - documentation (NXdetector.nxdl.xml:/amplifier_voltage): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector'] +DEBUG - NOT IN SCHEMA DEBUG - - Voltage applied to the amplifier. - DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/detector/amplifier_voltage@units) DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector', 'NX_FLOAT'] -DEBUG - classes: -NXdetector.nxdl.xml:/amplifier_voltage -DEBUG - NXdetector.nxdl.xml:/amplifier_voltage@units [NX_VOLTAGE] +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/instrument/electronanalyser/detector/detector_type): DEBUG - value: b'DLD' DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector', 'NX_CHAR'] DEBUG - classes: NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/DETECTOR/detector_type -NXdetector.nxdl.xml:/detector_type DEBUG - <> DEBUG - enumeration (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/DETECTOR/detector_type): DEBUG - -> DLD @@ -2214,36 +1973,21 @@ DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/DETECT DEBUG - Description of the detector type. -DEBUG - documentation (NXdetector.nxdl.xml:/detector_type): -DEBUG - - Description of the detector type, DLD, Phosphor+CCD, CMOS. - DEBUG - ===== FIELD (//entry/instrument/electronanalyser/detector/detector_voltage): DEBUG - value: 399.99712810186986 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector', 'NX_FLOAT'] -DEBUG - classes: -NXdetector.nxdl.xml:/detector_voltage -DEBUG - <> -DEBUG - documentation (NXdetector.nxdl.xml:/detector_voltage): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector'] +DEBUG - NOT IN SCHEMA DEBUG - - Voltage applied to detector. - DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/detector/detector_voltage@units) DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector', 'NX_FLOAT'] -DEBUG - classes: -NXdetector.nxdl.xml:/detector_voltage -DEBUG - NXdetector.nxdl.xml:/detector_voltage@units [NX_VOLTAGE] +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/instrument/electronanalyser/detector/sensor_pixels): DEBUG - value: [1800 1800] -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector', 'NX_INT'] -DEBUG - classes: -NXdetector.nxdl.xml:/sensor_pixels -DEBUG - <> -DEBUG - documentation (NXdetector.nxdl.xml:/sensor_pixels): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector'] +DEBUG - NOT IN SCHEMA DEBUG - - Number of raw active elements in each dimension. Important for swept scans. - DEBUG - ===== FIELD (//entry/instrument/electronanalyser/energy_resolution): DEBUG - value: 110.0 DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NX_FLOAT'] @@ -2283,8 +2027,8 @@ DEBUG - DEBUG - documentation (NXenergydispersion.nxdl.xml:): DEBUG - - Subclass of NXelectronanalyser to describe the energy dispersion - section of a photoelectron analyser. + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/energydispersion@NX_class) DEBUG - value: NXenergydispersion @@ -2697,22 +2441,15 @@ DEBUG - value: 140.0 DEBUG - classpath: ['NXentry', 'NXinstrument', 'NX_FLOAT'] DEBUG - classes: NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/energy_resolution -NXinstrument.nxdl.xml:/energy_resolution DEBUG - <> DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/energy_resolution): DEBUG - -DEBUG - documentation (NXinstrument.nxdl.xml:/energy_resolution): -DEBUG - - Energy resolution of the experiment (FWHM or gaussian broadening) - DEBUG - ===== ATTRS (//entry/instrument/energy_resolution@units) DEBUG - value: meV DEBUG - classpath: ['NXentry', 'NXinstrument', 'NX_FLOAT'] DEBUG - classes: NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/energy_resolution -NXinstrument.nxdl.xml:/energy_resolution DEBUG - NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/energy_resolution@units [NX_ENERGY] -DEBUG - NXinstrument.nxdl.xml:/energy_resolution@units [NX_ENERGY] DEBUG - ===== GROUP (//entry/instrument/manipulator [NXmpes::/NXentry/NXinstrument/NXmanipulator]): DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator'] DEBUG - classes: @@ -2725,8 +2462,8 @@ DEBUG - DEBUG - documentation (NXmanipulator.nxdl.xml:): DEBUG - - Extension of NXpositioner to include fields to describe the use of - manipulators in photoemission experiments. + Extension of NXpositioner to include fields to describe the use of manipulators + in photoemission experiments. DEBUG - ===== ATTRS (//entry/instrument/manipulator@NX_class) DEBUG - value: NXmanipulator @@ -3117,20 +2854,14 @@ DEBUG - DEBUG - ===== FIELD (//entry/instrument/momentum_resolution): DEBUG - value: 0.08 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NX_FLOAT'] -DEBUG - classes: -NXinstrument.nxdl.xml:/momentum_resolution -DEBUG - <> -DEBUG - documentation (NXinstrument.nxdl.xml:/momentum_resolution): +DEBUG - classpath: ['NXentry', 'NXinstrument'] +DEBUG - NOT IN SCHEMA DEBUG - - Momentum resolution of the experiment (FWHM) - DEBUG - ===== ATTRS (//entry/instrument/momentum_resolution@units) DEBUG - value: 1/angstrom -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NX_FLOAT'] -DEBUG - classes: -NXinstrument.nxdl.xml:/momentum_resolution -DEBUG - NXinstrument.nxdl.xml:/momentum_resolution@units [NX_WAVENUMBER] +DEBUG - classpath: ['NXentry', 'NXinstrument'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/instrument/name): DEBUG - value: b'Time-of-flight momentum microscope equipped delay line detector, at the endstation of the high rep-rate HHG source at FHI' DEBUG - classpath: ['NXentry', 'NXinstrument', 'NX_CHAR'] @@ -3138,9 +2869,7 @@ DEBUG - classes: NXinstrument.nxdl.xml:/name DEBUG - <> DEBUG - documentation (NXinstrument.nxdl.xml:/name): -DEBUG - - Name of instrument - +DEBUG - Name of instrument DEBUG - ===== ATTRS (//entry/instrument/name@short_name) DEBUG - value: TR-ARPES @ FHI DEBUG - classpath: ['NXentry', 'NXinstrument', 'NX_CHAR'] @@ -3149,9 +2878,7 @@ NXinstrument.nxdl.xml:/name DEBUG - NXinstrument.nxdl.xml:/name@short_name - [NX_CHAR] DEBUG - <> DEBUG - documentation (NXinstrument.nxdl.xml:/name/short_name): -DEBUG - - short name for instrument, perhaps the acronym - +DEBUG - short name for instrument, perhaps the acronym DEBUG - ===== GROUP (//entry/instrument/source [NXmpes::/NXentry/NXinstrument/NXsource]): DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] DEBUG - classes: @@ -3169,9 +2896,7 @@ DEBUG - DEBUG - documentation (NXinstrument.nxdl.xml:/SOURCE): DEBUG - DEBUG - documentation (NXsource.nxdl.xml:): -DEBUG - - The neutron or x-ray storage ring/facility. - +DEBUG - The neutron or x-ray storage ring/facility. DEBUG - ===== ATTRS (//entry/instrument/source@NX_class) DEBUG - value: NXsource DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] @@ -3188,9 +2913,7 @@ DEBUG - classes: NXsource.nxdl.xml:/frequency DEBUG - <> DEBUG - documentation (NXsource.nxdl.xml:/frequency): -DEBUG - - Frequency of pulsed source - +DEBUG - Frequency of pulsed source DEBUG - ===== ATTRS (//entry/instrument/source/frequency@units) DEBUG - value: kHz DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_FLOAT'] @@ -3207,9 +2930,7 @@ DEBUG - enumeration (NXsource.nxdl.xml:/mode): DEBUG - -> Single Bunch DEBUG - -> Multi Bunch DEBUG - documentation (NXsource.nxdl.xml:/mode): -DEBUG - - source operating mode - +DEBUG - source operating mode DEBUG - ===== FIELD (//entry/instrument/source/name): DEBUG - value: b'HHG @ TR-ARPES @ FHI' DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_CHAR'] @@ -3220,26 +2941,17 @@ DEBUG - <> DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/name): DEBUG - DEBUG - documentation (NXsource.nxdl.xml:/name): -DEBUG - - Name of source - +DEBUG - Name of source DEBUG - ===== FIELD (//entry/instrument/source/photon_energy): DEBUG - value: 21.7 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_FLOAT'] -DEBUG - classes: -NXsource.nxdl.xml:/photon_energy -DEBUG - <> -DEBUG - documentation (NXsource.nxdl.xml:/photon_energy): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] +DEBUG - NOT IN SCHEMA DEBUG - - The center photon energy of the source, before it is - monochromatized or converted - DEBUG - ===== ATTRS (//entry/instrument/source/photon_energy@units) DEBUG - value: eV -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_FLOAT'] -DEBUG - classes: -NXsource.nxdl.xml:/photon_energy -DEBUG - NXsource.nxdl.xml:/photon_energy@units [NX_ENERGY] +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/instrument/source/probe): DEBUG - value: b'ultraviolet' DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_CHAR'] @@ -3266,9 +2978,7 @@ DEBUG - restricted. DEBUG - documentation (NXsource.nxdl.xml:/probe): -DEBUG - - type of radiation probe (pick one from the enumerated list and spell exactly) - +DEBUG - type of radiation probe (pick one from the enumerated list and spell exactly) DEBUG - ===== FIELD (//entry/instrument/source/type): DEBUG - value: b'HHG laser' DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_CHAR'] @@ -3300,15 +3010,10 @@ DEBUG - -> Optical Laser DEBUG - -> Ion Source DEBUG - -> UV Plasma Source DEBUG - -> Metal Jet X-ray -DEBUG - -> Arc Lamp -DEBUG - -> Halogen Lamp -DEBUG - -> LED DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/type): DEBUG - DEBUG - documentation (NXsource.nxdl.xml:/type): -DEBUG - - type of radiation source (pick one from the enumerated list and spell exactly) - +DEBUG - type of radiation source (pick one from the enumerated list and spell exactly) DEBUG - ===== GROUP (//entry/instrument/source_pump [NXmpes::/NXentry/NXinstrument/NXsource]): DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] DEBUG - classes: @@ -3326,9 +3031,7 @@ DEBUG - DEBUG - documentation (NXinstrument.nxdl.xml:/SOURCE): DEBUG - DEBUG - documentation (NXsource.nxdl.xml:): -DEBUG - - The neutron or x-ray storage ring/facility. - +DEBUG - The neutron or x-ray storage ring/facility. DEBUG - ===== ATTRS (//entry/instrument/source_pump@NX_class) DEBUG - value: NXsource DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] @@ -3345,9 +3048,7 @@ DEBUG - classes: NXsource.nxdl.xml:/frequency DEBUG - <> DEBUG - documentation (NXsource.nxdl.xml:/frequency): -DEBUG - - Frequency of pulsed source - +DEBUG - Frequency of pulsed source DEBUG - ===== ATTRS (//entry/instrument/source_pump/frequency@units) DEBUG - value: kHz DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_FLOAT'] @@ -3364,9 +3065,7 @@ DEBUG - enumeration (NXsource.nxdl.xml:/mode): DEBUG - -> Single Bunch DEBUG - -> Multi Bunch DEBUG - documentation (NXsource.nxdl.xml:/mode): -DEBUG - - source operating mode - +DEBUG - source operating mode DEBUG - ===== FIELD (//entry/instrument/source_pump/name): DEBUG - value: b'OPCPA @ TR-ARPES @ FHI' DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_CHAR'] @@ -3377,26 +3076,17 @@ DEBUG - <> DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/name): DEBUG - DEBUG - documentation (NXsource.nxdl.xml:/name): -DEBUG - - Name of source - +DEBUG - Name of source DEBUG - ===== FIELD (//entry/instrument/source_pump/photon_energy): DEBUG - value: 1.2 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_FLOAT'] -DEBUG - classes: -NXsource.nxdl.xml:/photon_energy -DEBUG - <> -DEBUG - documentation (NXsource.nxdl.xml:/photon_energy): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] +DEBUG - NOT IN SCHEMA DEBUG - - The center photon energy of the source, before it is - monochromatized or converted - DEBUG - ===== ATTRS (//entry/instrument/source_pump/photon_energy@units) DEBUG - value: eV -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_FLOAT'] -DEBUG - classes: -NXsource.nxdl.xml:/photon_energy -DEBUG - NXsource.nxdl.xml:/photon_energy@units [NX_ENERGY] +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/instrument/source_pump/probe): DEBUG - value: b'visible light' DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_CHAR'] @@ -3423,9 +3113,7 @@ DEBUG - restricted. DEBUG - documentation (NXsource.nxdl.xml:/probe): -DEBUG - - type of radiation probe (pick one from the enumerated list and spell exactly) - +DEBUG - type of radiation probe (pick one from the enumerated list and spell exactly) DEBUG - ===== FIELD (//entry/instrument/source_pump/type): DEBUG - value: b'Optical Laser' DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_CHAR'] @@ -3457,31 +3145,20 @@ DEBUG - -> Optical Laser DEBUG - -> Ion Source DEBUG - -> UV Plasma Source DEBUG - -> Metal Jet X-ray -DEBUG - -> Arc Lamp -DEBUG - -> Halogen Lamp -DEBUG - -> LED DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/type): DEBUG - DEBUG - documentation (NXsource.nxdl.xml:/type): -DEBUG - - type of radiation source (pick one from the enumerated list and spell exactly) - +DEBUG - type of radiation source (pick one from the enumerated list and spell exactly) DEBUG - ===== FIELD (//entry/instrument/temporal_resolution): DEBUG - value: 35.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NX_FLOAT'] -DEBUG - classes: -NXinstrument.nxdl.xml:/temporal_resolution -DEBUG - <> -DEBUG - documentation (NXinstrument.nxdl.xml:/temporal_resolution): +DEBUG - classpath: ['NXentry', 'NXinstrument'] +DEBUG - NOT IN SCHEMA DEBUG - - Temporal resolution of the experiment (FWHM) - DEBUG - ===== ATTRS (//entry/instrument/temporal_resolution@units) DEBUG - value: fs -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NX_FLOAT'] -DEBUG - classes: -NXinstrument.nxdl.xml:/temporal_resolution -DEBUG - NXinstrument.nxdl.xml:/temporal_resolution@units [NX_TIME] +DEBUG - classpath: ['NXentry', 'NXinstrument'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== GROUP (//entry/process [NXmpes::/NXentry/NXprocess]): DEBUG - classpath: ['NXentry', 'NXprocess'] DEBUG - classes: @@ -3498,9 +3175,7 @@ DEBUG - DEBUG - documentation (NXentry.nxdl.xml:/PROCESS): DEBUG - DEBUG - documentation (NXprocess.nxdl.xml:): -DEBUG - - Document an event of data processing, reconstruction, or analysis for this data. - +DEBUG - Document an event of data processing, reconstruction, or analysis for this data. DEBUG - ===== ATTRS (//entry/process@NX_class) DEBUG - value: NXprocess DEBUG - classpath: ['NXentry', 'NXprocess'] @@ -3510,119 +3185,57 @@ NXentry.nxdl.xml:/PROCESS NXprocess.nxdl.xml: DEBUG - @NX_class [NX_CHAR] DEBUG - -DEBUG - ===== GROUP (//entry/process/distortion [NXmpes::/NXentry/NXprocess/NXdistortion]): -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXdistortion'] -DEBUG - classes: -NXprocess.nxdl.xml:/DISTORTION -NXdistortion.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXprocess.nxdl.xml:/DISTORTION): -DEBUG - - Describes the operations of image distortion correction - -DEBUG - documentation (NXdistortion.nxdl.xml:): -DEBUG - - Subclass of NXprocess to describe post-processing distortion correction. - -DEBUG - ===== ATTRS (//entry/process/distortion@NX_class) -DEBUG - value: NXdistortion -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXdistortion'] -DEBUG - classes: -NXprocess.nxdl.xml:/DISTORTION -NXdistortion.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] +DEBUG - ===== GROUP (//entry/process/distortion [NXmpes::/NXentry/NXprocess/distortion]): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - DEBUG - ===== FIELD (//entry/process/distortion/applied): DEBUG - value: True -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXdistortion', 'NX_BOOLEAN'] -DEBUG - classes: -NXdistortion.nxdl.xml:/applied -DEBUG - <> -DEBUG - documentation (NXdistortion.nxdl.xml:/applied): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - Has the distortion correction been applied? - DEBUG - ===== FIELD (//entry/process/distortion/cdeform_field): DEBUG - value: [0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. ... -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXdistortion', 'NX_FLOAT'] -DEBUG - classes: -NXdistortion.nxdl.xml:/cdeform_field -DEBUG - <> -DEBUG - documentation (NXdistortion.nxdl.xml:/cdeform_field): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - Column deformation field for general non-rigid distortion corrections. 2D matrix - holding the column information of the mapping of each original coordinate. - DEBUG - ===== FIELD (//entry/process/distortion/original_centre): DEBUG - value: [203. 215.] -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXdistortion', 'NX_FLOAT'] -DEBUG - classes: -NXdistortion.nxdl.xml:/original_centre -DEBUG - <> -DEBUG - documentation (NXdistortion.nxdl.xml:/original_centre): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - For symmetry-guided distortion correction. Here we record the coordinates of the - symmetry centre point. - DEBUG - ===== FIELD (//entry/process/distortion/original_points): DEBUG - value: [166. 283.] -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXdistortion', 'NX_FLOAT'] -DEBUG - classes: -NXdistortion.nxdl.xml:/original_points -DEBUG - <> -DEBUG - documentation (NXdistortion.nxdl.xml:/original_points): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - For symmetry-guided distortion correction. Here we record the coordinates of the - relevant symmetry points. - DEBUG - ===== FIELD (//entry/process/distortion/rdeform_field): DEBUG - value: [0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. ... -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXdistortion', 'NX_FLOAT'] -DEBUG - classes: -NXdistortion.nxdl.xml:/rdeform_field -DEBUG - <> -DEBUG - documentation (NXdistortion.nxdl.xml:/rdeform_field): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - Row deformation field for general non-rigid distortion corrections. 2D matrix - holding the row information of the mapping of each original coordinate. - DEBUG - ===== FIELD (//entry/process/distortion/symmetry): DEBUG - value: 6 -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXdistortion', 'NX_INT'] -DEBUG - classes: -NXdistortion.nxdl.xml:/symmetry -DEBUG - <> -DEBUG - documentation (NXdistortion.nxdl.xml:/symmetry): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - For `symmetry-guided distortion correction`_, - where a pattern of features is mapped to the regular geometric structure expected - from the symmetry. Here we record the number of elementary symmetry operations. - - .. _symmetry-guided distortion correction: https://www.sciencedirect.com/science/article/abs/pii/S0304399118303474?via%3Dihub - DEBUG - ===== GROUP (//entry/process/energy_calibration [NXmpes::/NXentry/NXprocess/NXcalibration]): DEBUG - classpath: ['NXentry', 'NXprocess', 'NXcalibration'] DEBUG - classes: NXmpes.nxdl.xml:/ENTRY/PROCESS/energy_calibration -NXprocess.nxdl.xml:/CALIBRATION NXcalibration.nxdl.xml: DEBUG - <> DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/PROCESS/energy_calibration): DEBUG - -DEBUG - documentation (NXprocess.nxdl.xml:/CALIBRATION): -DEBUG - - Describes the operations of calibration procedures, e.g. axis calibrations. - DEBUG - documentation (NXcalibration.nxdl.xml:): DEBUG - - Subclass of NXprocess to describe post-processing calibrations. + Subclass of NXprocess to describe post-processing calibrations. DEBUG - ===== ATTRS (//entry/process/energy_calibration@NX_class) DEBUG - value: NXcalibration DEBUG - classpath: ['NXentry', 'NXprocess', 'NXcalibration'] DEBUG - classes: NXmpes.nxdl.xml:/ENTRY/PROCESS/energy_calibration -NXprocess.nxdl.xml:/CALIBRATION NXcalibration.nxdl.xml: DEBUG - @NX_class [NX_CHAR] DEBUG - @@ -3683,504 +3296,152 @@ DEBUG - documentation (NXcalibration.nxdl.xml:/original_axis): DEBUG - Vector containing the data coordinates in the original uncalibrated axis -DEBUG - ===== GROUP (//entry/process/kx_calibration [NXmpes::/NXentry/NXprocess/NXcalibration]): -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXcalibration'] -DEBUG - classes: -NXprocess.nxdl.xml:/CALIBRATION -NXcalibration.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXprocess.nxdl.xml:/CALIBRATION): -DEBUG - - Describes the operations of calibration procedures, e.g. axis calibrations. - -DEBUG - documentation (NXcalibration.nxdl.xml:): -DEBUG - - Subclass of NXprocess to describe post-processing calibrations. - -DEBUG - ===== ATTRS (//entry/process/kx_calibration@NX_class) -DEBUG - value: NXcalibration -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXcalibration'] -DEBUG - classes: -NXprocess.nxdl.xml:/CALIBRATION -NXcalibration.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] +DEBUG - ===== GROUP (//entry/process/kx_calibration [NXmpes::/NXentry/NXprocess/kx_calibration]): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - DEBUG - ===== FIELD (//entry/process/kx_calibration/applied): DEBUG - value: True -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXcalibration', 'NX_BOOLEAN'] -DEBUG - classes: -NXcalibration.nxdl.xml:/applied -DEBUG - <> -DEBUG - documentation (NXcalibration.nxdl.xml:/applied): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - Has the calibration been applied? - DEBUG - ===== FIELD (//entry/process/kx_calibration/calibrated_axis): DEBUG - value: [-2.68021375 -2.66974416 -2.65927458 -2.64880499 -2.63833541 -2.62786582 ... -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXcalibration', 'NX_FLOAT'] -DEBUG - classes: -NXcalibration.nxdl.xml:/calibrated_axis -DEBUG - <> -DEBUG - documentation (NXcalibration.nxdl.xml:/calibrated_axis): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - A vector representing the axis after calibration, matching the data length - DEBUG - ===== FIELD (//entry/process/kx_calibration/offset): DEBUG - value: 256.0 -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXcalibration', 'NX_FLOAT'] -DEBUG - classes: -NXcalibration.nxdl.xml:/offset -DEBUG - <> -DEBUG - documentation (NXcalibration.nxdl.xml:/offset): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - For linear calibration. Offset parameter. - DEBUG - ===== FIELD (//entry/process/kx_calibration/scaling): DEBUG - value: 0.01046958495673419 -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXcalibration', 'NX_FLOAT'] -DEBUG - classes: -NXcalibration.nxdl.xml:/scaling -DEBUG - <> -DEBUG - documentation (NXcalibration.nxdl.xml:/scaling): -DEBUG - - For linear calibration. Scaling parameter. - -DEBUG - ===== GROUP (//entry/process/ky_calibration [NXmpes::/NXentry/NXprocess/NXcalibration]): -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXcalibration'] -DEBUG - classes: -NXprocess.nxdl.xml:/CALIBRATION -NXcalibration.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXprocess.nxdl.xml:/CALIBRATION): -DEBUG - - Describes the operations of calibration procedures, e.g. axis calibrations. - -DEBUG - documentation (NXcalibration.nxdl.xml:): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - Subclass of NXprocess to describe post-processing calibrations. - -DEBUG - ===== ATTRS (//entry/process/ky_calibration@NX_class) -DEBUG - value: NXcalibration -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXcalibration'] -DEBUG - classes: -NXprocess.nxdl.xml:/CALIBRATION -NXcalibration.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] +DEBUG - ===== GROUP (//entry/process/ky_calibration [NXmpes::/NXentry/NXprocess/ky_calibration]): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - DEBUG - ===== FIELD (//entry/process/ky_calibration/applied): DEBUG - value: True -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXcalibration', 'NX_BOOLEAN'] -DEBUG - classes: -NXcalibration.nxdl.xml:/applied -DEBUG - <> -DEBUG - documentation (NXcalibration.nxdl.xml:/applied): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - Has the calibration been applied? - DEBUG - ===== FIELD (//entry/process/ky_calibration/calibrated_axis): DEBUG - value: [-2.68021375 -2.66974416 -2.65927458 -2.64880499 -2.63833541 -2.62786582 ... -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXcalibration', 'NX_FLOAT'] -DEBUG - classes: -NXcalibration.nxdl.xml:/calibrated_axis -DEBUG - <> -DEBUG - documentation (NXcalibration.nxdl.xml:/calibrated_axis): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - A vector representing the axis after calibration, matching the data length - DEBUG - ===== FIELD (//entry/process/ky_calibration/offset): DEBUG - value: 256.0 -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXcalibration', 'NX_FLOAT'] -DEBUG - classes: -NXcalibration.nxdl.xml:/offset -DEBUG - <> -DEBUG - documentation (NXcalibration.nxdl.xml:/offset): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - For linear calibration. Offset parameter. - DEBUG - ===== FIELD (//entry/process/ky_calibration/scaling): DEBUG - value: 0.01046958495673419 -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXcalibration', 'NX_FLOAT'] -DEBUG - classes: -NXcalibration.nxdl.xml:/scaling -DEBUG - <> -DEBUG - documentation (NXcalibration.nxdl.xml:/scaling): -DEBUG - - For linear calibration. Scaling parameter. - -DEBUG - ===== GROUP (//entry/process/registration [NXmpes::/NXentry/NXprocess/NXregistration]): -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration'] -DEBUG - classes: -NXprocess.nxdl.xml:/REGISTRATION -NXregistration.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXprocess.nxdl.xml:/REGISTRATION): -DEBUG - - Describes the operations of image registration - -DEBUG - documentation (NXregistration.nxdl.xml:): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - Describes image registration procedures. - -DEBUG - ===== ATTRS (//entry/process/registration@NX_class) -DEBUG - value: NXregistration -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration'] -DEBUG - classes: -NXprocess.nxdl.xml:/REGISTRATION -NXregistration.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] +DEBUG - ===== GROUP (//entry/process/registration [NXmpes::/NXentry/NXprocess/registration]): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - DEBUG - ===== FIELD (//entry/process/registration/applied): DEBUG - value: True -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration', 'NX_BOOLEAN'] -DEBUG - classes: -NXregistration.nxdl.xml:/applied -DEBUG - <> -DEBUG - documentation (NXregistration.nxdl.xml:/applied): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - Has the registration been applied? - DEBUG - ===== FIELD (//entry/process/registration/depends_on): DEBUG - value: b'/entry/process/registration/tranformations/rot_z' -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration', 'NX_CHAR'] -DEBUG - classes: -NXregistration.nxdl.xml:/depends_on -DEBUG - <> -DEBUG - documentation (NXregistration.nxdl.xml:/depends_on): -DEBUG - - Specifies the position by pointing to the last transformation in the - transformation chain in the NXtransformations group. - -DEBUG - ===== GROUP (//entry/process/registration/tranformations [NXmpes::/NXentry/NXprocess/NXregistration/NXtransformations]): -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration', 'NXtransformations'] -DEBUG - classes: -NXregistration.nxdl.xml:/TRANSFORMATIONS -NXtransformations.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXregistration.nxdl.xml:/TRANSFORMATIONS): -DEBUG - - To describe the operations of image registration (combinations of rigid - translations and rotations) - -DEBUG - documentation (NXtransformations.nxdl.xml:): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - Collection of axis-based translations and rotations to describe a geometry. - May also contain axes that do not move and therefore do not have a transformation - type specified, but are useful in understanding coordinate frames within which - transformations are done, or in documenting important directions, such as the - direction of gravity. - - A nested sequence of transformations lists the translation and rotation steps - needed to describe the position and orientation of any movable or fixed device. - - There will be one or more transformations (axes) defined by one or more fields - for each transformation. Transformations can also be described by NXlog groups when - the values change with time. The all-caps name ``AXISNAME`` designates the - particular axis generating a transformation (e.g. a rotation axis or a translation - axis or a general axis). The attribute ``units="NX_TRANSFORMATION"`` designates the - units will be appropriate to the ``transformation_type`` attribute: - - * ``NX_LENGTH`` for ``translation`` - * ``NX_ANGLE`` for ``rotation`` - * ``NX_UNITLESS`` for axes for which no transformation type is specified - - This class will usually contain all axes of a sample stage or goniometer or - a detector. The NeXus default McSTAS coordinate frame is assumed, but additional - useful coordinate axes may be defined by using axes for which no transformation - type has been specified. - - The entry point (``depends_on``) will be outside of this class and point to a - field in here. Following the chain may also require following ``depends_on`` - links to transformations outside, for example to a common base table. If - a relative path is given, it is relative to the group enclosing the ``depends_on`` - specification. - - For a chain of three transformations, where :math:`T_1` depends on :math:`T_2` - and that in turn depends on :math:`T_3`, the final transformation :math:`T_f` is - - .. math:: T_f = T_3 T_2 T_1 - - In explicit terms, the transformations are a subset of affine transformations - expressed as 4x4 matrices that act on homogeneous coordinates, :math:`w=(x,y,z,1)^T`. - - For rotation and translation, - - .. math:: T_r &= \begin{pmatrix} R & o \\ 0_3 & 1 \end{pmatrix} \\ T_t &= \begin{pmatrix} I_3 & t + o \\ 0_3 & 1 \end{pmatrix} - - where :math:`R` is the usual 3x3 rotation matrix, :math:`o` is an offset vector, - :math:`0_3` is a row of 3 zeros, :math:`I_3` is the 3x3 identity matrix and - :math:`t` is the translation vector. - - :math:`o` is given by the ``offset`` attribute, :math:`t` is given by the ``vector`` - attribute multiplied by the field value, and :math:`R` is defined as a rotation - about an axis in the direction of ``vector``, of angle of the field value. - - NOTE - - One possible use of ``NXtransformations`` is to define the motors and - transformations for a diffractometer (goniometer). Such use is mentioned - in the ``NXinstrument`` base class. Use one ``NXtransformations`` group - for each diffractometer and name the group appropriate to the device. - Collecting the motors of a sample table or xyz-stage in an NXtransformations - group is equally possible. - - - Following the section on the general dscription of axis in NXtransformations is a section which - documents the fields commonly used within NeXus for positioning purposes and their meaning. Whenever - there is a need for positioning a beam line component please use the existing names. Use as many fields - as needed in order to position the component. Feel free to add more axis if required. In the description - given below, only those atttributes which are defined through the name are spcified. Add the other attributes - of the full set: - - * vector - * offset - * transformation_type - * depends_on - - as needed. - -DEBUG - ===== ATTRS (//entry/process/registration/tranformations@NX_class) -DEBUG - value: NXtransformations -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration', 'NXtransformations'] -DEBUG - classes: -NXregistration.nxdl.xml:/TRANSFORMATIONS -NXtransformations.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] +DEBUG - ===== GROUP (//entry/process/registration/tranformations [NXmpes::/NXentry/NXprocess/registration/tranformations]): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - DEBUG - ===== FIELD (//entry/process/registration/tranformations/rot_z): DEBUG - value: -1.0 -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - Units need to be appropriate for translation or rotation - - The name of this field is not forced. The user is free to use any name - that does not cause confusion. When using more than one ``AXISNAME`` field, - make sure that each field name is unique in the same group, as required - by HDF5. - - The values given should be the start points of exposures for the corresponding - frames. The end points should be given in ``AXISNAME_end``. - DEBUG - ===== ATTRS (//entry/process/registration/tranformations/rot_z@depends_on) DEBUG - value: trans_y -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@depends_on - [NX_CHAR] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/depends_on): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - Points to the path to a field defining the axis on which this - depends or the string ".". - DEBUG - ===== ATTRS (//entry/process/registration/tranformations/rot_z@offset) DEBUG - value: [256. 256. 0.] -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@offset - [NX_NUMBER] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/offset): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - A fixed offset applied before the transformation (three vector components). - This is not intended to be a substitute for a fixed ``translation`` axis but, for example, - as the mechanical offset from mounting the axis to its dependency. - DEBUG - ===== ATTRS (//entry/process/registration/tranformations/rot_z@transformation_type) DEBUG - value: rotation -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@transformation_type - [NX_CHAR] -DEBUG - <> -DEBUG - enumeration (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - -> translation -DEBUG - -> rotation -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - The transformation_type may be ``translation``, in which case the - values are linear displacements along the axis, ``rotation``, - in which case the values are angular rotations around the axis. - - If this attribute is omitted, this is an axis for which there - is no motion to be specifies, such as the direction of gravity, - or the direction to the source, or a basis vector of a - coordinate frame. - DEBUG - ===== ATTRS (//entry/process/registration/tranformations/rot_z@units) DEBUG - value: degrees -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@units [NX_TRANSFORMATION] +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== ATTRS (//entry/process/registration/tranformations/rot_z@vector) DEBUG - value: [0. 0. 1.] -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@vector - [NX_NUMBER] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/vector): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - Three values that define the axis for this transformation. - The axis should be normalized to unit length, making it - dimensionless. For ``rotation`` axes, the direction should be - chosen for a right-handed rotation with increasing angle. - For ``translation`` axes the direction should be chosen for - increasing displacement. For general axes, an appropriate direction - should be chosen. - DEBUG - ===== FIELD (//entry/process/registration/tranformations/trans_x): DEBUG - value: 43.0 -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - Units need to be appropriate for translation or rotation - - The name of this field is not forced. The user is free to use any name - that does not cause confusion. When using more than one ``AXISNAME`` field, - make sure that each field name is unique in the same group, as required - by HDF5. - - The values given should be the start points of exposures for the corresponding - frames. The end points should be given in ``AXISNAME_end``. - DEBUG - ===== ATTRS (//entry/process/registration/tranformations/trans_x@depends_on) DEBUG - value: . -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@depends_on - [NX_CHAR] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/depends_on): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - Points to the path to a field defining the axis on which this - depends or the string ".". - DEBUG - ===== ATTRS (//entry/process/registration/tranformations/trans_x@transformation_type) DEBUG - value: translation -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@transformation_type - [NX_CHAR] -DEBUG - <> -DEBUG - enumeration (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - -> translation -DEBUG - -> rotation -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - The transformation_type may be ``translation``, in which case the - values are linear displacements along the axis, ``rotation``, - in which case the values are angular rotations around the axis. - - If this attribute is omitted, this is an axis for which there - is no motion to be specifies, such as the direction of gravity, - or the direction to the source, or a basis vector of a - coordinate frame. - DEBUG - ===== ATTRS (//entry/process/registration/tranformations/trans_x@units) DEBUG - value: pixels -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@units [NX_TRANSFORMATION] +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== ATTRS (//entry/process/registration/tranformations/trans_x@vector) DEBUG - value: [1. 0. 0.] -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@vector - [NX_NUMBER] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/vector): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - Three values that define the axis for this transformation. - The axis should be normalized to unit length, making it - dimensionless. For ``rotation`` axes, the direction should be - chosen for a right-handed rotation with increasing angle. - For ``translation`` axes the direction should be chosen for - increasing displacement. For general axes, an appropriate direction - should be chosen. - DEBUG - ===== FIELD (//entry/process/registration/tranformations/trans_y): DEBUG - value: 55.0 -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - Units need to be appropriate for translation or rotation - - The name of this field is not forced. The user is free to use any name - that does not cause confusion. When using more than one ``AXISNAME`` field, - make sure that each field name is unique in the same group, as required - by HDF5. - - The values given should be the start points of exposures for the corresponding - frames. The end points should be given in ``AXISNAME_end``. - DEBUG - ===== ATTRS (//entry/process/registration/tranformations/trans_y@depends_on) DEBUG - value: trans_x -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@depends_on - [NX_CHAR] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/depends_on): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - Points to the path to a field defining the axis on which this - depends or the string ".". - DEBUG - ===== ATTRS (//entry/process/registration/tranformations/trans_y@transformation_type) DEBUG - value: translation -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@transformation_type - [NX_CHAR] -DEBUG - <> -DEBUG - enumeration (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - -> translation -DEBUG - -> rotation -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - The transformation_type may be ``translation``, in which case the - values are linear displacements along the axis, ``rotation``, - in which case the values are angular rotations around the axis. - - If this attribute is omitted, this is an axis for which there - is no motion to be specifies, such as the direction of gravity, - or the direction to the source, or a basis vector of a - coordinate frame. - DEBUG - ===== ATTRS (//entry/process/registration/tranformations/trans_y@units) DEBUG - value: pixels -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@units [NX_TRANSFORMATION] +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== ATTRS (//entry/process/registration/tranformations/trans_y@vector) DEBUG - value: [0. 1. 0.] -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXregistration', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@vector - [NX_NUMBER] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/vector): +DEBUG - classpath: ['NXentry', 'NXprocess'] +DEBUG - NOT IN SCHEMA DEBUG - - Three values that define the axis for this transformation. - The axis should be normalized to unit length, making it - dimensionless. For ``rotation`` axes, the direction should be - chosen for a right-handed rotation with increasing angle. - For ``translation`` axes the direction should be chosen for - increasing displacement. For general axes, an appropriate direction - should be chosen. - DEBUG - ===== GROUP (//entry/sample [NXmpes::/NXentry/NXsample]): DEBUG - classpath: ['NXentry', 'NXsample'] DEBUG - classes: @@ -4194,12 +3455,12 @@ DEBUG - documentation (NXentry.nxdl.xml:/SAMPLE): DEBUG - DEBUG - documentation (NXsample.nxdl.xml:): DEBUG - - Any information on the sample. - - This could include scanned variables that - are associated with one of the data dimensions, e.g. the magnetic field, or - logged data, e.g. monitored temperature vs elapsed time. - + Any information on the sample. + + This could include scanned variables that + are associated with one of the data dimensions, e.g. the magnetic field, or + logged data, e.g. monitored temperature vs elapsed time. + DEBUG - ===== ATTRS (//entry/sample@NX_class) DEBUG - value: NXsample DEBUG - classpath: ['NXentry', 'NXsample'] @@ -4211,20 +3472,14 @@ DEBUG - @NX_class [NX_CHAR] DEBUG - DEBUG - ===== FIELD (//entry/sample/bias): DEBUG - value: 17.799719004221362 -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_FLOAT'] -DEBUG - classes: -NXsample.nxdl.xml:/bias -DEBUG - <> -DEBUG - documentation (NXsample.nxdl.xml:/bias): +DEBUG - classpath: ['NXentry', 'NXsample'] +DEBUG - NOT IN SCHEMA DEBUG - - Voltage applied to sample and sample holder. - DEBUG - ===== ATTRS (//entry/sample/bias@units) DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_FLOAT'] -DEBUG - classes: -NXsample.nxdl.xml:/bias -DEBUG - NXsample.nxdl.xml:/bias@units [NX_VOLTAGE] +DEBUG - classpath: ['NXentry', 'NXsample'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/sample/chemical_formula): DEBUG - value: b'MoTe2' DEBUG - classpath: ['NXentry', 'NXsample', 'NX_CHAR'] @@ -4239,25 +3494,25 @@ DEBUG - DEBUG - documentation (NXsample.nxdl.xml:/chemical_formula): DEBUG - - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard: - - * Only recognized element symbols may be used. - * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. - * A space or parenthesis must separate each cluster of (element symbol + count). - * Where a group of elements is enclosed in parentheses, the multiplier for the - group must follow the closing parentheses. That is, all element and group - multipliers are assumed to be printed as subscripted numbers. - * Unless the elements are ordered in a manner that corresponds to their chemical - structure, the order of the elements within any group or moiety depends on - whether or not carbon is present. - * If carbon is present, the order should be: - - - C, then H, then the other elements in alphabetical order of their symbol. - - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. - - * This is the *Hill* system used by Chemical Abstracts. - + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard: + + * Only recognized element symbols may be used. + * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. + * A space or parenthesis must separate each cluster of (element symbol + count). + * Where a group of elements is enclosed in parentheses, the multiplier for the + group must follow the closing parentheses. That is, all element and group + multipliers are assumed to be printed as subscripted numbers. + * Unless the elements are ordered in a manner that corresponds to their chemical + structure, the order of the elements within any group or moiety depends on + whether or not carbon is present. + * If carbon is present, the order should be: + + - C, then H, then the other elements in alphabetical order of their symbol. + - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. + + * This is the *Hill* system used by Chemical Abstracts. + DEBUG - ===== FIELD (//entry/sample/depends_on): DEBUG - value: b'/entry/sample/transformations/corrected_phi' DEBUG - classpath: ['NXentry', 'NXsample', 'NX_CHAR'] @@ -4266,12 +3521,12 @@ NXsample.nxdl.xml:/depends_on DEBUG - <> DEBUG - documentation (NXsample.nxdl.xml:/depends_on): DEBUG - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. DEBUG - ===== FIELD (//entry/sample/description): DEBUG - value: b'MoTe2' @@ -4281,8 +3536,8 @@ NXsample.nxdl.xml:/description DEBUG - <> DEBUG - documentation (NXsample.nxdl.xml:/description): DEBUG - - Description of the sample - + Description of the sample + DEBUG - ===== FIELD (//entry/sample/gas_pressure): DEBUG - value: 4.5599999999999996e-11 DEBUG - classpath: ['NXentry', 'NXsample', 'NX_FLOAT'] @@ -4307,9 +3562,7 @@ DEBUG - <> DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/SAMPLE/name): DEBUG - DEBUG - documentation (NXsample.nxdl.xml:/name): -DEBUG - - Descriptive name of sample - +DEBUG - Descriptive name of sample DEBUG - ===== FIELD (//entry/sample/preparation_date): DEBUG - value: b'2019-05-22T14:00:00+00:00' DEBUG - classpath: ['NXentry', 'NXsample', 'NX_DATE_TIME'] @@ -4323,9 +3576,7 @@ DEBUG - annealing). DEBUG - documentation (NXsample.nxdl.xml:/preparation_date): -DEBUG - - Date of preparation of the sample - +DEBUG - Date of preparation of the sample DEBUG - ===== GROUP (//entry/sample/preparation_description [NXmpes::/NXentry/NXsample/NXnote]): DEBUG - classpath: ['NXentry', 'NXsample', 'NXnote'] DEBUG - classes: @@ -4367,7 +3618,6 @@ DEBUG - ===== GROUP (//entry/sample/sample_history [NXmpes::/NXentry/NXsample/NX DEBUG - classpath: ['NXentry', 'NXsample', 'NXnote'] DEBUG - classes: NXmpes.nxdl.xml:/ENTRY/SAMPLE/sample_history -NXsample.nxdl.xml:/sample_history NXnote.nxdl.xml: DEBUG - <> DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/SAMPLE/sample_history): @@ -4378,14 +3628,6 @@ DEBUG - reference to the location or a unique identifier or other metadata file. In the case these are not available, free-text description. -DEBUG - documentation (NXsample.nxdl.xml:/sample_history): -DEBUG - - 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 - DEBUG - documentation (NXnote.nxdl.xml:): DEBUG - Any additional freeform information not covered by the other base classes. @@ -4398,7 +3640,6 @@ DEBUG - value: NXnote DEBUG - classpath: ['NXentry', 'NXsample', 'NXnote'] DEBUG - classes: NXmpes.nxdl.xml:/ENTRY/SAMPLE/sample_history -NXsample.nxdl.xml:/sample_history NXnote.nxdl.xml: DEBUG - @NX_class [NX_CHAR] DEBUG - @@ -4434,10 +3675,10 @@ DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/SAMPLE/situation): DEBUG - DEBUG - documentation (NXsample.nxdl.xml:/situation): DEBUG - - The atmosphere will be one of the components, which is where - its details will be stored; the relevant components will be - indicated by the entry in the sample_component member. - + The atmosphere will be one of the components, which is where + its details will be stored; the relevant components will be + indicated by the entry in the sample_component member. + DEBUG - ===== FIELD (//entry/sample/temperature): DEBUG - value: 23.050763803680983 DEBUG - classpath: ['NXentry', 'NXsample', 'NX_FLOAT'] @@ -4453,9 +3694,7 @@ DEBUG - /entry/instrument/manipulator/sample_temperature. DEBUG - documentation (NXsample.nxdl.xml:/temperature): -DEBUG - - Sample temperature. This could be a scanned variable - +DEBUG - Sample temperature. This could be a scanned variable DEBUG - ===== ATTRS (//entry/sample/temperature@units) DEBUG - value: K DEBUG - classpath: ['NXentry', 'NXsample', 'NX_FLOAT'] @@ -4472,10 +3711,10 @@ NXtransformations.nxdl.xml: DEBUG - <> DEBUG - documentation (NXsample.nxdl.xml:/TRANSFORMATIONS): DEBUG - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. DEBUG - documentation (NXtransformations.nxdl.xml:): DEBUG - @@ -5092,9 +4331,7 @@ DEBUG - Datetime of the start of the measurement. DEBUG - documentation (NXentry.nxdl.xml:/start_time): -DEBUG - - Starting time of measurement - +DEBUG - Starting time of measurement DEBUG - ===== FIELD (//entry/title): DEBUG - value: b'Valence Band Dynamics - 1030 nm linear p-polarized pump, 0.6 mJ/cm2 absorbed fluence' DEBUG - classpath: ['NXentry', 'NX_CHAR'] @@ -5105,9 +4342,7 @@ DEBUG - <> DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/title): DEBUG - DEBUG - documentation (NXentry.nxdl.xml:/title): -DEBUG - - Extended title for entry - +DEBUG - Extended title for entry DEBUG - ===== GROUP (//entry/user [NXmpes::/NXentry/NXuser]): DEBUG - classpath: ['NXentry', 'NXuser'] DEBUG - classes: diff --git a/tests/data/nexus/Ref_nexus_test.log b/tests/data/nexus/Ref_nexus_test.log index 87cc1c258..1319a9986 100644 --- a/tests/data/nexus/Ref_nexus_test.log +++ b/tests/data/nexus/Ref_nexus_test.log @@ -8,13 +8,12 @@ DEBUG - documentation (NXarpes.nxdl.xml:/ENTRY): DEBUG - DEBUG - documentation (NXentry.nxdl.xml:): DEBUG - - (**required**) :ref:`NXentry` describes the measurement. - - The top-level NeXus group which contains all the data and associated - information that comprise a single measurement. - It is mandatory that there is at least one - group of this type in the NeXus file. - + (**required**) :ref:`NXentry` describes the measurement. + + The top-level NeXus group which contains all the data and associated + information that comprise a single measurement. + It is mandatory that there is at least one + group of this type in the NeXus file. DEBUG - ===== ATTRS (//entry@NX_class) DEBUG - value: NXentry DEBUG - classpath: ['NXentry'] @@ -31,9 +30,9 @@ NXentry.nxdl.xml:/collection_time DEBUG - <> DEBUG - documentation (NXentry.nxdl.xml:/collection_time): DEBUG - - Time transpired actually collecting data i.e. taking out time when collection was - suspended due to e.g. temperature out of range - + Time transpired actually collecting data i.e. taking out time when collection was + suspended due to e.g. temperature out of range + DEBUG - ===== ATTRS (//entry/collection_time@units) DEBUG - value: s DEBUG - classpath: ['NXentry', 'NX_FLOAT'] @@ -51,33 +50,34 @@ DEBUG - documentation (NXarpes.nxdl.xml:/ENTRY/DATA): DEBUG - DEBUG - documentation (NXentry.nxdl.xml:/DATA): DEBUG - - The data group - - .. note:: Before the NIAC2016 meeting [#]_, at least one - :ref:`NXdata` group was required in each :ref:`NXentry` group. - At the NIAC2016 meeting, it was decided to make :ref:`NXdata` - an optional group in :ref:`NXentry` groups for data files that - do not use an application definition. - It is recommended strongly that all NeXus data files provide - a NXdata group. - It is permissable to omit the NXdata group only when - defining the default plot is not practical or possible - from the available data. - - For example, neutron event data may not have anything that - makes a useful plot without extensive processing. - - Certain application definitions override this decision and - require an :ref:`NXdata` group - in the :ref:`NXentry` group. The ``minOccurs=0`` attribute - in the application definition will indicate the - :ref:`NXdata` group - is optional, otherwise, it is required. - - .. [#] NIAC2016: - https://www.nexusformat.org/NIAC2016.html, - https://github.com/nexusformat/NIAC/issues/16 - + The data group + + .. note:: Before the NIAC2016 meeting [#]_, at least one + :ref:`NXdata` group was required in each :ref:`NXentry` group. + At the NIAC2016 meeting, it was decided to make :ref:`NXdata` + an optional group in :ref:`NXentry` groups for data files that + do not use an application definition. + It is recommended strongly that all NeXus data files provide + a NXdata group. + It is permissable to omit the NXdata group only when + defining the default plot is not practical or possible + from the available data. + + For example, neutron event data may not have anything that + makes a useful plot without extensive processing. + + Certain application definitions override this decision and + require an :ref:`NXdata` group + in the :ref:`NXentry` group. The ``minOccurs=0`` attribute + in the application definition will indicate the + :ref:`NXdata` group + is optional, otherwise, it is required. + + .. [#] NIAC2016: + https://www.nexusformat.org/NIAC2016.html, + https://github.com/nexusformat/NIAC/issues/16 + + DEBUG - documentation (NXdata.nxdl.xml:): DEBUG - :ref:`NXdata` describes the plottable data and related dimension scales. @@ -395,21 +395,21 @@ DEBUG - documentation (NXarpes.nxdl.xml:/ENTRY/definition): DEBUG - Official NeXus NXDL schema to which this file conforms. DEBUG - documentation (NXentry.nxdl.xml:/definition): DEBUG - - (alternate use: see same field in :ref:`NXsubentry` for preferred) - - Official NeXus NXDL schema to which this entry conforms which must be - the name of the NXDL file (case sensitive without the file extension) - that the NXDL schema is defined in. - - For example the ``definition`` field for a file that conformed to the - *NXarpes.nxdl.xml* definition must contain the string **NXarpes**. - - This field is provided so that :ref:`NXentry` can be the overlay position - in a NeXus data file for an application definition and its - set of groups, fields, and attributes. - - *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. - + (alternate use: see same field in :ref:`NXsubentry` for preferred) + + Official NeXus NXDL schema to which this entry conforms which must be + the name of the NXDL file (case sensitive without the file extension) + that the NXDL schema is defined in. + + For example the ``definition`` field for a file that conformed to the + *NXarpes.nxdl.xml* definition must contain the string **NXarpes**. + + This field is provided so that :ref:`NXentry` can be the overlay position + in a NeXus data file for an application definition and its + set of groups, fields, and attributes. + + *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. + DEBUG - ===== FIELD (//entry/duration): DEBUG - value: 7200 DEBUG - classpath: ['NXentry', 'NX_INT'] @@ -417,9 +417,7 @@ DEBUG - classes: NXentry.nxdl.xml:/duration DEBUG - <> DEBUG - documentation (NXentry.nxdl.xml:/duration): -DEBUG - - Duration of measurement - +DEBUG - Duration of measurement DEBUG - ===== ATTRS (//entry/duration@units) DEBUG - value: s DEBUG - classpath: ['NXentry', 'NX_INT'] @@ -433,9 +431,7 @@ DEBUG - classes: NXentry.nxdl.xml:/end_time DEBUG - <> DEBUG - documentation (NXentry.nxdl.xml:/end_time): -DEBUG - - Ending time of measurement - +DEBUG - Ending time of measurement DEBUG - ===== FIELD (//entry/entry_identifier): DEBUG - value: b'Run 22118' DEBUG - classpath: ['NXentry', 'NX_CHAR'] @@ -443,9 +439,7 @@ DEBUG - classes: NXentry.nxdl.xml:/entry_identifier DEBUG - <> DEBUG - documentation (NXentry.nxdl.xml:/entry_identifier): -DEBUG - - Unique identifier for the measurement, defined by the facility. - +DEBUG - unique identifier for the measurement, defined by the facility. DEBUG - ===== FIELD (//entry/experiment_identifier): DEBUG - value: b'F-20170538' DEBUG - classpath: ['NXentry', 'NX_CHAR'] @@ -454,10 +448,10 @@ NXentry.nxdl.xml:/experiment_identifier DEBUG - <> DEBUG - documentation (NXentry.nxdl.xml:/experiment_identifier): DEBUG - - 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 + DEBUG - ===== GROUP (//entry/instrument [NXarpes::/NXentry/NXinstrument]): DEBUG - classpath: ['NXentry', 'NXinstrument'] DEBUG - classes: @@ -471,15 +465,15 @@ DEBUG - documentation (NXentry.nxdl.xml:/INSTRUMENT): DEBUG - DEBUG - documentation (NXinstrument.nxdl.xml:): DEBUG - - Collection of the components of the instrument or beamline. - - Template of instrument descriptions comprising various beamline components. - Each component will also be a NeXus group defined by its distance from the - sample. Negative distances represent beamline components that are before the - sample while positive distances represent components that are after the sample. - This device allows the unique identification of beamline components in a way - that is valid for both reactor and pulsed instrumentation. - + Collection of the components of the instrument or beamline. + + Template of instrument descriptions comprising various beamline components. + Each component will also be a NeXus group defined by its distance from the + sample. Negative distances represent beamline components that are before the + sample while positive distances represent components that are after the sample. + This device allows the unique identification of beamline components in a way + that is valid for both reactor and pulsed instrumentation. + DEBUG - ===== ATTRS (//entry/instrument@NX_class) DEBUG - value: NXinstrument DEBUG - classpath: ['NXentry', 'NXinstrument'] @@ -502,8 +496,8 @@ DEBUG - documentation (NXinstrument.nxdl.xml:/DETECTOR): DEBUG - DEBUG - documentation (NXdetector.nxdl.xml:): DEBUG - - A detector, detector bank, or multidetector. - + A detector, detector bank, or multidetector. + DEBUG - ===== ATTRS (//entry/instrument/analyser@NX_class) DEBUG - value: NXdetector DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXdetector'] @@ -533,19 +527,12 @@ DEBUG - -> decimated DEBUG - documentation (NXarpes.nxdl.xml:/ENTRY/INSTRUMENT/analyser/acquisition_mode): DEBUG - DEBUG - documentation (NXdetector.nxdl.xml:/acquisition_mode): -DEBUG - - The acquisition mode of the detector. - +DEBUG - The acquisition mode of the detector. DEBUG - ===== FIELD (//entry/instrument/analyser/amplifier_type): DEBUG - value: b'MCP' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXdetector', 'NX_CHAR'] -DEBUG - classes: -NXdetector.nxdl.xml:/amplifier_type -DEBUG - <> -DEBUG - documentation (NXdetector.nxdl.xml:/amplifier_type): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXdetector'] +DEBUG - NOT IN SCHEMA DEBUG - - Type of electron amplifier, MCP, channeltron, etc. - DEBUG - ===== FIELD (//entry/instrument/analyser/angles): DEBUG - value: [-1.96735314 -1.91500657 -1.86266001 -1.81031344 -1.75796688 -1.70562031 ... DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXdetector', 'NX_NUMBER'] @@ -587,29 +574,29 @@ DEBUG - documentation (NXarpes.nxdl.xml:/ENTRY/INSTRUMENT/analyser/data): DEBUG - DEBUG - documentation (NXdetector.nxdl.xml:/data): DEBUG - - Data values from the detector. The rank and dimension ordering should follow a principle of - slowest to fastest measurement axes and may be explicitly specified in application definitions. - - Mechanical scanning of objects (e.g. sample position/angle, incident beam energy, etc) tends to be - the slowest part of an experiment and so any such scan axes should be allocated to the first dimensions - of the array. Note that in some cases it may be useful to represent a 2D set of scan points as a single - scan-axis in the data array, especially if the scan pattern doesn't fit a rectangular array nicely. - Repetition of an experiment in a time series tends to be used similar to a slow scan axis - and so will often be in the first dimension of the data array. - - The next fastest axes are typically the readout of the detector. A point detector will not add any dimensions - (as it is just a single value per scan point) to the data array, a strip detector will add one dimension, an - imaging detector will add two dimensions (e.g. X, Y axes) and detectors outputting higher dimensional data - will add the corresponding number of dimensions. Note that the detector dimensions don't necessarily have to - be written in order of the actual readout speeds - the slowest to fastest rule principle is only a guide. - - Finally, detectors that operate in a time-of-flight mode, such as a neutron spectrometer or a silicon drift - detector (used for X-ray fluorescence) tend to have their dimension(s) added to the last dimensions in the data array. - - The type of each dimension should should follow the order of scan points, detector pixels, - then time-of-flight (i.e. spectroscopy, spectrometry). The rank and dimension sizes (see symbol list) - shown here are merely illustrative of coordination between related datasets. - + Data values from the detector. The rank and dimension ordering should follow a principle of + slowest to fastest measurement axes and may be explicitly specified in application definitions. + + Mechanical scanning of objects (e.g. sample position/angle, incident beam energy, etc) tends to be + the slowest part of an experiment and so any such scan axes should be allocated to the first dimensions + of the array. Note that in some cases it may be useful to represent a 2D set of scan points as a single + scan-axis in the data array, especially if the scan pattern doesn't fit a rectangular array nicely. + Repetition of an experiment in a time series tends to be used similar to a slow scan axis + and so will often be in the first dimension of the data array. + + The next fastest axes are typically the readout of the detector. A point detector will not add any dimensions + (as it is just a single value per scan point) to the data array, a strip detector will add one dimension, an + imaging detector will add two dimensions (e.g. X, Y axes) and detectors outputting higher dimensional data + will add the corresponding number of dimensions. Note that the detector dimensions don't necessarily have to + be written in order of the actual readout speeds - the slowest to fastest rule principle is only a guide. + + Finally, detectors that operate in a time-of-flight mode, such as a neutron spectrometer or a silicon drift + detector (used for X-ray fluorescence) tend to have their dimension(s) added to the last dimensions in the data array. + + The type of each dimension should should follow the order of scan points, detector pixels, + then time-of-flight (i.e. spectroscopy, spectrometry). The rank and dimension sizes (see symbol list) + shown here are merely illustrative of coordination between related datasets. + DEBUG - ===== ATTRS (//entry/instrument/analyser/data@target) DEBUG - value: /entry/instrument/analyser/data DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXdetector', 'NX_NUMBER'] @@ -643,14 +630,9 @@ DEBUG - NOT IN SCHEMA DEBUG - DEBUG - ===== FIELD (//entry/instrument/analyser/detector_type): DEBUG - value: b'DLD' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXdetector', 'NX_CHAR'] -DEBUG - classes: -NXdetector.nxdl.xml:/detector_type -DEBUG - <> -DEBUG - documentation (NXdetector.nxdl.xml:/detector_type): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXdetector'] +DEBUG - NOT IN SCHEMA DEBUG - - Description of the detector type, DLD, Phosphor+CCD, CMOS. - DEBUG - ===== FIELD (//entry/instrument/analyser/dispersion_scheme): DEBUG - value: b'Time of flight' DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXdetector'] @@ -794,14 +776,9 @@ DEBUG - documentation (NXarpes.nxdl.xml:/ENTRY/INSTRUMENT/analyser/region_size): DEBUG - size of rectangular region selected for readout DEBUG - ===== FIELD (//entry/instrument/analyser/sensor_count): DEBUG - value: 4 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXdetector', 'NX_INT'] -DEBUG - classes: -NXdetector.nxdl.xml:/sensor_count -DEBUG - <> -DEBUG - documentation (NXdetector.nxdl.xml:/sensor_count): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXdetector'] +DEBUG - NOT IN SCHEMA DEBUG - - Number of imaging sensor chips on the detector. - DEBUG - ===== FIELD (//entry/instrument/analyser/sensor_size): DEBUG - value: [ 80 146] DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXdetector', 'NX_INT'] @@ -844,19 +821,22 @@ DEBUG - documentation (NXinstrument.nxdl.xml:/BEAM): DEBUG - DEBUG - documentation (NXbeam.nxdl.xml:): DEBUG - - Properties of the neutron or X-ray beam at a given location. - - This group is intended to be referenced - by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. This group is - especially valuable in storing the results of instrument simulations in which it is useful - to specify the beam profile, time distribution etc. at each beamline component. Otherwise, - its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron - scattering by the sample, e.g., energy transfer, polarizations. - - Note that incident_wavelength and related fields can be a scalar values or arrays, depending on the use case. - To support these use cases, the explicit dimensionality of these fields is not specified, but it can be inferred - by the presense of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam. - + Properties of the neutron or X-ray beam at a given location. + + This group is intended to be referenced + by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. This group is + especially valuable in storing the results of instrument simulations in which it is useful + to specify the beam profile, time distribution etc. at each beamline component. Otherwise, + its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron + scattering by the sample, e.g., energy transfer, polarizations. Finally, There are cases where the beam is + considered as a beamline component and this group may be defined as a subgroup directly inside + :ref:`NXinstrument`, in which case it is recommended that the position of the beam is specified by an + :ref:`NXtransformations` group, unless the beam is at the origin (which is the sample). + + Note that incident_wavelength and related fields can be a scalar values or arrays, depending on the use case. + To support these use cases, the explicit dimensionality of these fields is not specified, but it can be inferred + by the presense of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam. + DEBUG - ===== ATTRS (//entry/instrument/beam_probe_0@NX_class) DEBUG - value: NXbeam DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] @@ -872,9 +852,7 @@ DEBUG - classes: NXbeam.nxdl.xml:/distance DEBUG - <> DEBUG - documentation (NXbeam.nxdl.xml:/distance): -DEBUG - - Distance from sample. Note, it is recommended to use NXtransformations instead. - +DEBUG - Distance from sample. Note, it is recommended to use NXtransformations instead. DEBUG - ===== ATTRS (//entry/instrument/beam_probe_0/distance@units) DEBUG - value: cm DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] @@ -908,20 +886,14 @@ DEBUG - NOT IN SCHEMA DEBUG - DEBUG - ===== FIELD (//entry/instrument/beam_probe_0/pulse_duration): DEBUG - value: 70 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/pulse_duration -DEBUG - <> -DEBUG - documentation (NXbeam.nxdl.xml:/pulse_duration): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] +DEBUG - NOT IN SCHEMA DEBUG - - FWHM duration of the pulses at the diagnostic point - DEBUG - ===== ATTRS (//entry/instrument/beam_probe_0/pulse_duration@units) DEBUG - value: fs -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/pulse_duration -DEBUG - NXbeam.nxdl.xml:/pulse_duration@units [NX_TIME] +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/instrument/beam_probe_0/size_x): DEBUG - value: 500 DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] @@ -952,19 +924,22 @@ DEBUG - documentation (NXinstrument.nxdl.xml:/BEAM): DEBUG - DEBUG - documentation (NXbeam.nxdl.xml:): DEBUG - - Properties of the neutron or X-ray beam at a given location. - - This group is intended to be referenced - by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. This group is - especially valuable in storing the results of instrument simulations in which it is useful - to specify the beam profile, time distribution etc. at each beamline component. Otherwise, - its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron - scattering by the sample, e.g., energy transfer, polarizations. - - Note that incident_wavelength and related fields can be a scalar values or arrays, depending on the use case. - To support these use cases, the explicit dimensionality of these fields is not specified, but it can be inferred - by the presense of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam. - + Properties of the neutron or X-ray beam at a given location. + + This group is intended to be referenced + by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. This group is + especially valuable in storing the results of instrument simulations in which it is useful + to specify the beam profile, time distribution etc. at each beamline component. Otherwise, + its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron + scattering by the sample, e.g., energy transfer, polarizations. Finally, There are cases where the beam is + considered as a beamline component and this group may be defined as a subgroup directly inside + :ref:`NXinstrument`, in which case it is recommended that the position of the beam is specified by an + :ref:`NXtransformations` group, unless the beam is at the origin (which is the sample). + + Note that incident_wavelength and related fields can be a scalar values or arrays, depending on the use case. + To support these use cases, the explicit dimensionality of these fields is not specified, but it can be inferred + by the presense of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam. + DEBUG - ===== ATTRS (//entry/instrument/beam_pump_0@NX_class) DEBUG - value: NXbeam DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] @@ -975,20 +950,14 @@ DEBUG - @NX_class [NX_CHAR] DEBUG - DEBUG - ===== FIELD (//entry/instrument/beam_pump_0/average_power): DEBUG - value: 6.21289 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/average_power -DEBUG - <> -DEBUG - documentation (NXbeam.nxdl.xml:/average_power): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] +DEBUG - NOT IN SCHEMA DEBUG - - Average power at the diagnostic point - DEBUG - ===== ATTRS (//entry/instrument/beam_pump_0/average_power@units) DEBUG - value: uW -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/average_power -DEBUG - NXbeam.nxdl.xml:/average_power@units [NX_POWER] +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/instrument/beam_pump_0/center_wavelength): DEBUG - value: 800 DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] @@ -1006,9 +975,7 @@ DEBUG - classes: NXbeam.nxdl.xml:/distance DEBUG - <> DEBUG - documentation (NXbeam.nxdl.xml:/distance): -DEBUG - - Distance from sample. Note, it is recommended to use NXtransformations instead. - +DEBUG - Distance from sample. Note, it is recommended to use NXtransformations instead. DEBUG - ===== ATTRS (//entry/instrument/beam_pump_0/distance@units) DEBUG - value: cm DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] @@ -1017,20 +984,14 @@ NXbeam.nxdl.xml:/distance DEBUG - NXbeam.nxdl.xml:/distance@units [NX_LENGTH] DEBUG - ===== FIELD (//entry/instrument/beam_pump_0/fluence): DEBUG - value: 5 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/fluence -DEBUG - <> -DEBUG - documentation (NXbeam.nxdl.xml:/fluence): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] +DEBUG - NOT IN SCHEMA DEBUG - - Incident fluence at the diagnostic point - DEBUG - ===== ATTRS (//entry/instrument/beam_pump_0/fluence@units) DEBUG - value: mJ/cm^2 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/fluence -DEBUG - NXbeam.nxdl.xml:/fluence@units [NX_ANY] +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/instrument/beam_pump_0/photon_energy): DEBUG - value: 1.55 DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] @@ -1058,36 +1019,24 @@ DEBUG - NOT IN SCHEMA DEBUG - DEBUG - ===== FIELD (//entry/instrument/beam_pump_0/pulse_duration): DEBUG - value: 50 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/pulse_duration -DEBUG - <> -DEBUG - documentation (NXbeam.nxdl.xml:/pulse_duration): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] +DEBUG - NOT IN SCHEMA DEBUG - - FWHM duration of the pulses at the diagnostic point - DEBUG - ===== ATTRS (//entry/instrument/beam_pump_0/pulse_duration@units) DEBUG - value: fs -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/pulse_duration -DEBUG - NXbeam.nxdl.xml:/pulse_duration@units [NX_TIME] +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/instrument/beam_pump_0/pulse_energy): DEBUG - value: 1.24258 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/pulse_energy -DEBUG - <> -DEBUG - documentation (NXbeam.nxdl.xml:/pulse_energy): +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] +DEBUG - NOT IN SCHEMA DEBUG - - Energy of a single pulse at the diagnostic point - DEBUG - ===== ATTRS (//entry/instrument/beam_pump_0/pulse_energy@units) DEBUG - value: nJ -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/pulse_energy -DEBUG - NXbeam.nxdl.xml:/pulse_energy@units [NX_ENERGY] +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/instrument/beam_pump_0/size_x): DEBUG - value: 500 DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] @@ -1110,20 +1059,14 @@ DEBUG - NOT IN SCHEMA DEBUG - DEBUG - ===== FIELD (//entry/instrument/energy_resolution): DEBUG - value: 100 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NX_FLOAT'] -DEBUG - classes: -NXinstrument.nxdl.xml:/energy_resolution -DEBUG - <> -DEBUG - documentation (NXinstrument.nxdl.xml:/energy_resolution): +DEBUG - classpath: ['NXentry', 'NXinstrument'] +DEBUG - NOT IN SCHEMA DEBUG - - Energy resolution of the experiment (FWHM or gaussian broadening) - DEBUG - ===== ATTRS (//entry/instrument/energy_resolution@units) DEBUG - value: meV -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NX_FLOAT'] -DEBUG - classes: -NXinstrument.nxdl.xml:/energy_resolution -DEBUG - NXinstrument.nxdl.xml:/energy_resolution@units [NX_ENERGY] +DEBUG - classpath: ['NXentry', 'NXinstrument'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== GROUP (//entry/instrument/manipulator [NXarpes::/NXentry/NXinstrument/NXpositioner]): DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXpositioner'] DEBUG - classes: @@ -1329,9 +1272,7 @@ DEBUG - classes: NXinstrument.nxdl.xml:/name DEBUG - <> DEBUG - documentation (NXinstrument.nxdl.xml:/name): -DEBUG - - Name of instrument - +DEBUG - Name of instrument DEBUG - ===== GROUP (//entry/instrument/source [NXarpes::/NXentry/NXinstrument/NXsource]): DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] DEBUG - classes: @@ -1344,9 +1285,7 @@ DEBUG - DEBUG - documentation (NXinstrument.nxdl.xml:/SOURCE): DEBUG - DEBUG - documentation (NXsource.nxdl.xml:): -DEBUG - - The neutron or x-ray storage ring/facility. - +DEBUG - The neutron or x-ray storage ring/facility. DEBUG - ===== ATTRS (//entry/instrument/source@NX_class) DEBUG - value: NXsource DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] @@ -1363,9 +1302,7 @@ DEBUG - classes: NXsource.nxdl.xml:/bunch_distance DEBUG - <> DEBUG - documentation (NXsource.nxdl.xml:/bunch_distance): -DEBUG - - For storage rings, time between bunches - +DEBUG - For storage rings, time between bunches DEBUG - ===== ATTRS (//entry/instrument/source/bunch_distance@units) DEBUG - value: us DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_FLOAT'] @@ -1379,9 +1316,7 @@ DEBUG - classes: NXsource.nxdl.xml:/bunch_length DEBUG - <> DEBUG - documentation (NXsource.nxdl.xml:/bunch_length): -DEBUG - - For storage rings, temporal length of the bunch - +DEBUG - For storage rings, temporal length of the bunch DEBUG - ===== ATTRS (//entry/instrument/source/bunch_length@units) DEBUG - value: fs DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_FLOAT'] @@ -1425,9 +1360,7 @@ DEBUG - classes: NXsource.nxdl.xml:/current DEBUG - <> DEBUG - documentation (NXsource.nxdl.xml:/current): -DEBUG - - Accelerator, X-ray tube, or storage ring current - +DEBUG - Accelerator, X-ray tube, or storage ring current DEBUG - ===== ATTRS (//entry/instrument/source/current@units) DEBUG - value: uA DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_FLOAT'] @@ -1442,10 +1375,10 @@ NXsource.nxdl.xml:/energy DEBUG - <> DEBUG - documentation (NXsource.nxdl.xml:/energy): DEBUG - - Source energy. - For storage rings, this would be the particle beam energy. - For X-ray tubes, this would be the excitation voltage. - + Source energy. + For storage rings, this would be the particle beam energy. + For X-ray tubes, this would be the excitation voltage. + DEBUG - ===== ATTRS (//entry/instrument/source/energy@units) DEBUG - value: MeV DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_FLOAT'] @@ -1459,9 +1392,7 @@ DEBUG - classes: NXsource.nxdl.xml:/frequency DEBUG - <> DEBUG - documentation (NXsource.nxdl.xml:/frequency): -DEBUG - - Frequency of pulsed source - +DEBUG - Frequency of pulsed source DEBUG - ===== ATTRS (//entry/instrument/source/frequency@units) DEBUG - value: Hz DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_FLOAT'] @@ -1478,9 +1409,7 @@ DEBUG - enumeration (NXsource.nxdl.xml:/mode): DEBUG - -> Single Bunch DEBUG - -> Multi Bunch DEBUG - documentation (NXsource.nxdl.xml:/mode): -DEBUG - - source operating mode - +DEBUG - source operating mode DEBUG - ===== FIELD (//entry/instrument/source/name): DEBUG - value: b'FLASH' DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_CHAR'] @@ -1491,9 +1420,7 @@ DEBUG - <> DEBUG - documentation (NXarpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/name): DEBUG - DEBUG - documentation (NXsource.nxdl.xml:/name): -DEBUG - - Name of source - +DEBUG - Name of source DEBUG - ===== FIELD (//entry/instrument/source/number_of_bunches): DEBUG - value: 500 DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_INT'] @@ -1501,9 +1428,7 @@ DEBUG - classes: NXsource.nxdl.xml:/number_of_bunches DEBUG - <> DEBUG - documentation (NXsource.nxdl.xml:/number_of_bunches): -DEBUG - - For storage rings, the number of bunches in use. - +DEBUG - For storage rings, the number of bunches in use. DEBUG - ===== FIELD (//entry/instrument/source/number_of_bursts): DEBUG - value: 1 DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] @@ -1530,9 +1455,7 @@ DEBUG - -> proton DEBUG - documentation (NXarpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/probe): DEBUG - DEBUG - documentation (NXsource.nxdl.xml:/probe): -DEBUG - - type of radiation probe (pick one from the enumerated list and spell exactly) - +DEBUG - type of radiation probe (pick one from the enumerated list and spell exactly) DEBUG - ===== FIELD (//entry/instrument/source/top_up): DEBUG - value: True DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_BOOLEAN'] @@ -1540,9 +1463,7 @@ DEBUG - classes: NXsource.nxdl.xml:/top_up DEBUG - <> DEBUG - documentation (NXsource.nxdl.xml:/top_up): -DEBUG - - Is the synchrotron operating in top_up mode? - +DEBUG - Is the synchrotron operating in top_up mode? DEBUG - ===== FIELD (//entry/instrument/source/type): DEBUG - value: b'Free Electron Laser' DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_CHAR'] @@ -1564,15 +1485,10 @@ DEBUG - -> Optical Laser DEBUG - -> Ion Source DEBUG - -> UV Plasma Source DEBUG - -> Metal Jet X-ray -DEBUG - -> Arc Lamp -DEBUG - -> Halogen Lamp -DEBUG - -> LED DEBUG - documentation (NXarpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/type): DEBUG - DEBUG - documentation (NXsource.nxdl.xml:/type): -DEBUG - - type of radiation source (pick one from the enumerated list and spell exactly) - +DEBUG - type of radiation source (pick one from the enumerated list and spell exactly) DEBUG - ===== GROUP (//entry/instrument/source_pump [NXarpes::/NXentry/NXinstrument/NXsource]): DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] DEBUG - classes: @@ -1585,9 +1501,7 @@ DEBUG - DEBUG - documentation (NXinstrument.nxdl.xml:/SOURCE): DEBUG - DEBUG - documentation (NXsource.nxdl.xml:): -DEBUG - - The neutron or x-ray storage ring/facility. - +DEBUG - The neutron or x-ray storage ring/facility. DEBUG - ===== ATTRS (//entry/instrument/source_pump@NX_class) DEBUG - value: NXsource DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] @@ -1604,9 +1518,7 @@ DEBUG - classes: NXsource.nxdl.xml:/bunch_distance DEBUG - <> DEBUG - documentation (NXsource.nxdl.xml:/bunch_distance): -DEBUG - - For storage rings, time between bunches - +DEBUG - For storage rings, time between bunches DEBUG - ===== ATTRS (//entry/instrument/source_pump/bunch_distance@units) DEBUG - value: us DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_FLOAT'] @@ -1620,9 +1532,7 @@ DEBUG - classes: NXsource.nxdl.xml:/bunch_length DEBUG - <> DEBUG - documentation (NXsource.nxdl.xml:/bunch_length): -DEBUG - - For storage rings, temporal length of the bunch - +DEBUG - For storage rings, temporal length of the bunch DEBUG - ===== ATTRS (//entry/instrument/source_pump/bunch_length@units) DEBUG - value: fs DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_FLOAT'] @@ -1656,9 +1566,7 @@ DEBUG - classes: NXsource.nxdl.xml:/frequency DEBUG - <> DEBUG - documentation (NXsource.nxdl.xml:/frequency): -DEBUG - - Frequency of pulsed source - +DEBUG - Frequency of pulsed source DEBUG - ===== ATTRS (//entry/instrument/source_pump/frequency@units) DEBUG - value: Hz DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_FLOAT'] @@ -1675,9 +1583,7 @@ DEBUG - enumeration (NXsource.nxdl.xml:/mode): DEBUG - -> Single Bunch DEBUG - -> Multi Bunch DEBUG - documentation (NXsource.nxdl.xml:/mode): -DEBUG - - source operating mode - +DEBUG - source operating mode DEBUG - ===== FIELD (//entry/instrument/source_pump/name): DEBUG - value: b'User Laser @ FLASH' DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_CHAR'] @@ -1688,9 +1594,7 @@ DEBUG - <> DEBUG - documentation (NXarpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/name): DEBUG - DEBUG - documentation (NXsource.nxdl.xml:/name): -DEBUG - - Name of source - +DEBUG - Name of source DEBUG - ===== FIELD (//entry/instrument/source_pump/number_of_bunches): DEBUG - value: 400 DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_INT'] @@ -1698,9 +1602,7 @@ DEBUG - classes: NXsource.nxdl.xml:/number_of_bunches DEBUG - <> DEBUG - documentation (NXsource.nxdl.xml:/number_of_bunches): -DEBUG - - For storage rings, the number of bunches in use. - +DEBUG - For storage rings, the number of bunches in use. DEBUG - ===== FIELD (//entry/instrument/source_pump/number_of_bursts): DEBUG - value: 1 DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] @@ -1727,9 +1629,7 @@ DEBUG - -> proton DEBUG - documentation (NXarpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/probe): DEBUG - DEBUG - documentation (NXsource.nxdl.xml:/probe): -DEBUG - - type of radiation probe (pick one from the enumerated list and spell exactly) - +DEBUG - type of radiation probe (pick one from the enumerated list and spell exactly) DEBUG - ===== FIELD (//entry/instrument/source_pump/rms_jitter): DEBUG - value: 204.68816194453154 DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] @@ -1761,47 +1661,30 @@ DEBUG - -> Optical Laser DEBUG - -> Ion Source DEBUG - -> UV Plasma Source DEBUG - -> Metal Jet X-ray -DEBUG - -> Arc Lamp -DEBUG - -> Halogen Lamp -DEBUG - -> LED DEBUG - documentation (NXarpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/type): DEBUG - DEBUG - documentation (NXsource.nxdl.xml:/type): -DEBUG - - type of radiation source (pick one from the enumerated list and spell exactly) - +DEBUG - type of radiation source (pick one from the enumerated list and spell exactly) DEBUG - ===== FIELD (//entry/instrument/spatial_resolution): DEBUG - value: 500 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NX_FLOAT'] -DEBUG - classes: -NXinstrument.nxdl.xml:/spatial_resolution -DEBUG - <> -DEBUG - documentation (NXinstrument.nxdl.xml:/spatial_resolution): +DEBUG - classpath: ['NXentry', 'NXinstrument'] +DEBUG - NOT IN SCHEMA DEBUG - - Spatial resolution of the experiment (Airy disk radius) - DEBUG - ===== ATTRS (//entry/instrument/spatial_resolution@units) DEBUG - value: um -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NX_FLOAT'] -DEBUG - classes: -NXinstrument.nxdl.xml:/spatial_resolution -DEBUG - NXinstrument.nxdl.xml:/spatial_resolution@units [NX_LENGTH] +DEBUG - classpath: ['NXentry', 'NXinstrument'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/instrument/temporal_resolution): DEBUG - value: 100 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NX_FLOAT'] -DEBUG - classes: -NXinstrument.nxdl.xml:/temporal_resolution -DEBUG - <> -DEBUG - documentation (NXinstrument.nxdl.xml:/temporal_resolution): +DEBUG - classpath: ['NXentry', 'NXinstrument'] +DEBUG - NOT IN SCHEMA DEBUG - - Temporal resolution of the experiment (FWHM) - DEBUG - ===== ATTRS (//entry/instrument/temporal_resolution@units) DEBUG - value: fs -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NX_FLOAT'] -DEBUG - classes: -NXinstrument.nxdl.xml:/temporal_resolution -DEBUG - NXinstrument.nxdl.xml:/temporal_resolution@units [NX_TIME] +DEBUG - classpath: ['NXentry', 'NXinstrument'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/run_cycle): DEBUG - value: b'2018 User Run Block 2' DEBUG - classpath: ['NXentry', 'NX_CHAR'] @@ -1809,9 +1692,7 @@ DEBUG - classes: NXentry.nxdl.xml:/run_cycle DEBUG - <> DEBUG - documentation (NXentry.nxdl.xml:/run_cycle): -DEBUG - - Such as "2007-3". Some user facilities organize their beam time into run cycles. - +DEBUG - Such as "2007-3". Some user facilities organize their beam time into run cycles. DEBUG - ===== GROUP (//entry/sample [NXarpes::/NXentry/NXsample]): DEBUG - classpath: ['NXentry', 'NXsample'] DEBUG - classes: @@ -1825,12 +1706,12 @@ DEBUG - documentation (NXentry.nxdl.xml:/SAMPLE): DEBUG - DEBUG - documentation (NXsample.nxdl.xml:): DEBUG - - Any information on the sample. - - This could include scanned variables that - are associated with one of the data dimensions, e.g. the magnetic field, or - logged data, e.g. monitored temperature vs elapsed time. - + Any information on the sample. + + This could include scanned variables that + are associated with one of the data dimensions, e.g. the magnetic field, or + logged data, e.g. monitored temperature vs elapsed time. + DEBUG - ===== ATTRS (//entry/sample@NX_class) DEBUG - value: NXsample DEBUG - classpath: ['NXentry', 'NXsample'] @@ -1842,68 +1723,39 @@ DEBUG - @NX_class [NX_CHAR] DEBUG - DEBUG - ===== FIELD (//entry/sample/bias): DEBUG - value: 29 -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_FLOAT'] -DEBUG - classes: -NXsample.nxdl.xml:/bias -DEBUG - <> -DEBUG - documentation (NXsample.nxdl.xml:/bias): +DEBUG - classpath: ['NXentry', 'NXsample'] +DEBUG - NOT IN SCHEMA DEBUG - - Voltage applied to sample and sample holder. - DEBUG - ===== ATTRS (//entry/sample/bias@target) DEBUG - value: /entry/instrument/manipulator/sample_bias -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_FLOAT'] -DEBUG - classes: -NXsample.nxdl.xml:/bias -DEBUG - @target - IS NOT IN SCHEMA +DEBUG - classpath: ['NXentry', 'NXsample'] +DEBUG - NOT IN SCHEMA DEBUG - DEBUG - ===== ATTRS (//entry/sample/bias@units) DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_FLOAT'] -DEBUG - classes: -NXsample.nxdl.xml:/bias -DEBUG - NXsample.nxdl.xml:/bias@units [NX_VOLTAGE] +DEBUG - classpath: ['NXentry', 'NXsample'] +DEBUG - NOT IN SCHEMA +DEBUG - DEBUG - ===== FIELD (//entry/sample/chem_id_cas): DEBUG - value: b'12067-46-8' -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_CHAR'] -DEBUG - classes: -NXsample.nxdl.xml:/chem_id_cas -DEBUG - <> -DEBUG - documentation (NXsample.nxdl.xml:/chem_id_cas): +DEBUG - classpath: ['NXentry', 'NXsample'] +DEBUG - NOT IN SCHEMA DEBUG - - CAS registry number of the sample chemical content. - DEBUG - ===== FIELD (//entry/sample/chemical_name): DEBUG - value: b'Tungsten diselenide' -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_CHAR'] -DEBUG - classes: -NXsample.nxdl.xml:/chemical_name -DEBUG - <> -DEBUG - documentation (NXsample.nxdl.xml:/chemical_name): +DEBUG - classpath: ['NXentry', 'NXsample'] +DEBUG - NOT IN SCHEMA DEBUG - - Full chemical name of the sample - DEBUG - ===== FIELD (//entry/sample/growth_method): DEBUG - value: b'Chemical Vapor Deposition' -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_CHAR'] -DEBUG - classes: -NXsample.nxdl.xml:/growth_method -DEBUG - <> -DEBUG - documentation (NXsample.nxdl.xml:/growth_method): +DEBUG - classpath: ['NXentry', 'NXsample'] +DEBUG - NOT IN SCHEMA DEBUG - - Sample growth method (e. g. molecular beam epitaxy, chemical vapor deposition - etc.) - DEBUG - ===== FIELD (//entry/sample/layer): DEBUG - value: b'bulk' -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_CHAR'] -DEBUG - classes: -NXsample.nxdl.xml:/layer -DEBUG - <> -DEBUG - documentation (NXsample.nxdl.xml:/layer): +DEBUG - classpath: ['NXentry', 'NXsample'] +DEBUG - NOT IN SCHEMA DEBUG - - Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) - DEBUG - ===== FIELD (//entry/sample/name): DEBUG - value: b'WSe2' DEBUG - classpath: ['NXentry', 'NXsample', 'NX_CHAR'] @@ -1914,9 +1766,7 @@ DEBUG - <> DEBUG - documentation (NXarpes.nxdl.xml:/ENTRY/SAMPLE/name): DEBUG - Descriptive name of sample DEBUG - documentation (NXsample.nxdl.xml:/name): -DEBUG - - Descriptive name of sample - +DEBUG - Descriptive name of sample DEBUG - ===== FIELD (//entry/sample/preparation_method): DEBUG - value: b'in-vacuum cleave' DEBUG - classpath: ['NXentry', 'NXsample'] @@ -1929,9 +1779,7 @@ DEBUG - classes: NXsample.nxdl.xml:/pressure DEBUG - <> DEBUG - documentation (NXsample.nxdl.xml:/pressure): -DEBUG - - Applied pressure - +DEBUG - Applied pressure DEBUG - ===== ATTRS (//entry/sample/pressure@units) DEBUG - value: mbar DEBUG - classpath: ['NXentry', 'NXsample', 'NX_FLOAT'] @@ -1940,24 +1788,14 @@ NXsample.nxdl.xml:/pressure DEBUG - NXsample.nxdl.xml:/pressure@units [NX_PRESSURE] DEBUG - ===== FIELD (//entry/sample/purity): DEBUG - value: 0.999 -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_FLOAT'] -DEBUG - classes: -NXsample.nxdl.xml:/purity -DEBUG - <> -DEBUG - documentation (NXsample.nxdl.xml:/purity): +DEBUG - classpath: ['NXentry', 'NXsample'] +DEBUG - NOT IN SCHEMA DEBUG - - Chemical purity of the sample - DEBUG - ===== FIELD (//entry/sample/state): DEBUG - value: b'monocrystalline solid' -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_CHAR'] -DEBUG - classes: -NXsample.nxdl.xml:/state -DEBUG - <> -DEBUG - documentation (NXsample.nxdl.xml:/state): +DEBUG - classpath: ['NXentry', 'NXsample'] +DEBUG - NOT IN SCHEMA DEBUG - - Physical state of the sample - DEBUG - ===== FIELD (//entry/sample/surface_orientation): DEBUG - value: b'0001' DEBUG - classpath: ['NXentry', 'NXsample'] @@ -1991,9 +1829,7 @@ DEBUG - classes: NXsample.nxdl.xml:/thickness DEBUG - <> DEBUG - documentation (NXsample.nxdl.xml:/thickness): -DEBUG - - sample thickness - +DEBUG - sample thickness DEBUG - ===== ATTRS (//entry/sample/thickness@units) DEBUG - value: mm DEBUG - classpath: ['NXentry', 'NXsample', 'NX_FLOAT'] @@ -2002,14 +1838,9 @@ NXsample.nxdl.xml:/thickness DEBUG - NXsample.nxdl.xml:/thickness@units [NX_LENGTH] DEBUG - ===== FIELD (//entry/sample/vendor): DEBUG - value: b'HQ Graphene' -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_CHAR'] -DEBUG - classes: -NXsample.nxdl.xml:/vendor -DEBUG - <> -DEBUG - documentation (NXsample.nxdl.xml:/vendor): +DEBUG - classpath: ['NXentry', 'NXsample'] +DEBUG - NOT IN SCHEMA DEBUG - - Name of the sample vendor (company or research group) - DEBUG - ===== FIELD (//entry/start_time): DEBUG - value: b'2018-05-01T07:22:00+02:00' DEBUG - classpath: ['NXentry', 'NX_DATE_TIME'] @@ -2020,9 +1851,7 @@ DEBUG - <> DEBUG - documentation (NXarpes.nxdl.xml:/ENTRY/start_time): DEBUG - DEBUG - documentation (NXentry.nxdl.xml:/start_time): -DEBUG - - Starting time of measurement - +DEBUG - Starting time of measurement DEBUG - ===== FIELD (//entry/title): DEBUG - value: b'Excited-state dynamics of WSe2 in the Valence Band and Core-Levels' DEBUG - classpath: ['NXentry', 'NX_CHAR'] @@ -2033,9 +1862,7 @@ DEBUG - <> DEBUG - documentation (NXarpes.nxdl.xml:/ENTRY/title): DEBUG - DEBUG - documentation (NXentry.nxdl.xml:/title): -DEBUG - - Extended title for entry - +DEBUG - Extended title for entry DEBUG - ======================== DEBUG - === Default Plotable === DEBUG - ======================== @@ -2065,3 +1892,57 @@ DEBUG - DEBUG - For Axis #1, 1 axes have been identified: [] DEBUG - DEBUG - For Axis #2, 1 axes have been identified: [] +INFO - entry/instrument/beam_probe_0 +INFO - entry/instrument/beam_pump_0 +INFO - entry/instrument/analyser/data +INFO - entry/data@signal +DEBUG - ===== FIELD (//entry/instrument/analyser/data): +DEBUG - value: [[0.0000000e+00 0.0000000e+00 0.0000000e+00 0.0000000e+00 0.0000000e+00 ... +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXdetector', 'NX_NUMBER'] +DEBUG - classes: +NXarpes.nxdl.xml:/ENTRY/INSTRUMENT/analyser/data +NXdetector.nxdl.xml:/data +DEBUG - <> +DEBUG - documentation (NXarpes.nxdl.xml:/ENTRY/INSTRUMENT/analyser/data): +DEBUG - +DEBUG - documentation (NXdetector.nxdl.xml:/data): +DEBUG - + Data values from the detector. The rank and dimension ordering should follow a principle of + slowest to fastest measurement axes and may be explicitly specified in application definitions. + + Mechanical scanning of objects (e.g. sample position/angle, incident beam energy, etc) tends to be + the slowest part of an experiment and so any such scan axes should be allocated to the first dimensions + of the array. Note that in some cases it may be useful to represent a 2D set of scan points as a single + scan-axis in the data array, especially if the scan pattern doesn't fit a rectangular array nicely. + Repetition of an experiment in a time series tends to be used similar to a slow scan axis + and so will often be in the first dimension of the data array. + + The next fastest axes are typically the readout of the detector. A point detector will not add any dimensions + (as it is just a single value per scan point) to the data array, a strip detector will add one dimension, an + imaging detector will add two dimensions (e.g. X, Y axes) and detectors outputting higher dimensional data + will add the corresponding number of dimensions. Note that the detector dimensions don't necessarily have to + be written in order of the actual readout speeds - the slowest to fastest rule principle is only a guide. + + Finally, detectors that operate in a time-of-flight mode, such as a neutron spectrometer or a silicon drift + detector (used for X-ray fluorescence) tend to have their dimension(s) added to the last dimensions in the data array. + + The type of each dimension should should follow the order of scan points, detector pixels, + then time-of-flight (i.e. spectroscopy, spectrometry). The rank and dimension sizes (see symbol list) + shown here are merely illustrative of coordination between related datasets. + +DEBUG - ===== ATTRS (//entry/instrument/analyser/data@target) +DEBUG - value: /entry/instrument/analyser/data +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXdetector', 'NX_NUMBER'] +DEBUG - classes: +NXarpes.nxdl.xml:/ENTRY/INSTRUMENT/analyser/data +NXdetector.nxdl.xml:/data +DEBUG - @target - IS NOT IN SCHEMA +DEBUG - +DEBUG - ===== ATTRS (//entry/instrument/analyser/data@units) +DEBUG - value: counts +DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXdetector', 'NX_NUMBER'] +DEBUG - classes: +NXarpes.nxdl.xml:/ENTRY/INSTRUMENT/analyser/data +NXdetector.nxdl.xml:/data +DEBUG - NXarpes.nxdl.xml:/ENTRY/INSTRUMENT/analyser/data@units - REQUIRED, but undefined unit category +DEBUG - NXdetector.nxdl.xml:/data@units [NX_ANY] From ed1cf73999b55db1964a53a7bf16aa9e58dc7792 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Thu, 20 Jul 2023 16:20:58 +0200 Subject: [PATCH 12/18] removing test output from other tests --- tests/data/nexus/Ref_nexus_test.log | 54 ----------------------------- 1 file changed, 54 deletions(-) diff --git a/tests/data/nexus/Ref_nexus_test.log b/tests/data/nexus/Ref_nexus_test.log index 1319a9986..0b9f8bebd 100644 --- a/tests/data/nexus/Ref_nexus_test.log +++ b/tests/data/nexus/Ref_nexus_test.log @@ -1892,57 +1892,3 @@ DEBUG - DEBUG - For Axis #1, 1 axes have been identified: [] DEBUG - DEBUG - For Axis #2, 1 axes have been identified: [] -INFO - entry/instrument/beam_probe_0 -INFO - entry/instrument/beam_pump_0 -INFO - entry/instrument/analyser/data -INFO - entry/data@signal -DEBUG - ===== FIELD (//entry/instrument/analyser/data): -DEBUG - value: [[0.0000000e+00 0.0000000e+00 0.0000000e+00 0.0000000e+00 0.0000000e+00 ... -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXdetector', 'NX_NUMBER'] -DEBUG - classes: -NXarpes.nxdl.xml:/ENTRY/INSTRUMENT/analyser/data -NXdetector.nxdl.xml:/data -DEBUG - <> -DEBUG - documentation (NXarpes.nxdl.xml:/ENTRY/INSTRUMENT/analyser/data): -DEBUG - -DEBUG - documentation (NXdetector.nxdl.xml:/data): -DEBUG - - Data values from the detector. The rank and dimension ordering should follow a principle of - slowest to fastest measurement axes and may be explicitly specified in application definitions. - - Mechanical scanning of objects (e.g. sample position/angle, incident beam energy, etc) tends to be - the slowest part of an experiment and so any such scan axes should be allocated to the first dimensions - of the array. Note that in some cases it may be useful to represent a 2D set of scan points as a single - scan-axis in the data array, especially if the scan pattern doesn't fit a rectangular array nicely. - Repetition of an experiment in a time series tends to be used similar to a slow scan axis - and so will often be in the first dimension of the data array. - - The next fastest axes are typically the readout of the detector. A point detector will not add any dimensions - (as it is just a single value per scan point) to the data array, a strip detector will add one dimension, an - imaging detector will add two dimensions (e.g. X, Y axes) and detectors outputting higher dimensional data - will add the corresponding number of dimensions. Note that the detector dimensions don't necessarily have to - be written in order of the actual readout speeds - the slowest to fastest rule principle is only a guide. - - Finally, detectors that operate in a time-of-flight mode, such as a neutron spectrometer or a silicon drift - detector (used for X-ray fluorescence) tend to have their dimension(s) added to the last dimensions in the data array. - - The type of each dimension should should follow the order of scan points, detector pixels, - then time-of-flight (i.e. spectroscopy, spectrometry). The rank and dimension sizes (see symbol list) - shown here are merely illustrative of coordination between related datasets. - -DEBUG - ===== ATTRS (//entry/instrument/analyser/data@target) -DEBUG - value: /entry/instrument/analyser/data -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXdetector', 'NX_NUMBER'] -DEBUG - classes: -NXarpes.nxdl.xml:/ENTRY/INSTRUMENT/analyser/data -NXdetector.nxdl.xml:/data -DEBUG - @target - IS NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/analyser/data@units) -DEBUG - value: counts -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXdetector', 'NX_NUMBER'] -DEBUG - classes: -NXarpes.nxdl.xml:/ENTRY/INSTRUMENT/analyser/data -NXdetector.nxdl.xml:/data -DEBUG - NXarpes.nxdl.xml:/ENTRY/INSTRUMENT/analyser/data@units - REQUIRED, but undefined unit category -DEBUG - NXdetector.nxdl.xml:/data@units [NX_ANY] From 0d427c92f88586cb9698b63b803cce2bb324253d Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Thu, 31 Aug 2023 16:21:34 +0200 Subject: [PATCH 13/18] updated nexus defs fairmat branch --- pynxtools/definitions | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pynxtools/definitions b/pynxtools/definitions index 400ac9bdd..81c322910 160000 --- a/pynxtools/definitions +++ b/pynxtools/definitions @@ -1 +1 @@ -Subproject commit 400ac9bddd7aa0907bc18f610e5c1dec7087fb16 +Subproject commit 81c3229100a9a8b1be4085cf16a65b279975757d From bffa864becfd1f0211226bed4bcb3a063c9a26a2 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Thu, 31 Aug 2023 16:47:39 +0200 Subject: [PATCH 14/18] Fixed tests --- .../readers/mpes/Ref_nexus_mpes.log | 94 ++++++++++--------- tests/data/nexus/Ref_nexus_test.log | 24 +++-- 2 files changed, 65 insertions(+), 53 deletions(-) diff --git a/tests/data/dataconverter/readers/mpes/Ref_nexus_mpes.log b/tests/data/dataconverter/readers/mpes/Ref_nexus_mpes.log index 35c7fb42f..c4a87661e 100644 --- a/tests/data/dataconverter/readers/mpes/Ref_nexus_mpes.log +++ b/tests/data/dataconverter/readers/mpes/Ref_nexus_mpes.log @@ -3455,12 +3455,12 @@ DEBUG - documentation (NXentry.nxdl.xml:/SAMPLE): DEBUG - DEBUG - documentation (NXsample.nxdl.xml:): DEBUG - - Any information on the sample. - - This could include scanned variables that - are associated with one of the data dimensions, e.g. the magnetic field, or - logged data, e.g. monitored temperature vs elapsed time. - + Any information on the sample. + + This could include scanned variables that + are associated with one of the data dimensions, e.g. the magnetic field, or + logged data, e.g. monitored temperature vs elapsed time. + DEBUG - ===== ATTRS (//entry/sample@NX_class) DEBUG - value: NXsample DEBUG - classpath: ['NXentry', 'NXsample'] @@ -3494,25 +3494,25 @@ DEBUG - DEBUG - documentation (NXsample.nxdl.xml:/chemical_formula): DEBUG - - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard: - - * Only recognized element symbols may be used. - * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. - * A space or parenthesis must separate each cluster of (element symbol + count). - * Where a group of elements is enclosed in parentheses, the multiplier for the - group must follow the closing parentheses. That is, all element and group - multipliers are assumed to be printed as subscripted numbers. - * Unless the elements are ordered in a manner that corresponds to their chemical - structure, the order of the elements within any group or moiety depends on - whether or not carbon is present. - * If carbon is present, the order should be: - - - C, then H, then the other elements in alphabetical order of their symbol. - - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. - - * This is the *Hill* system used by Chemical Abstracts. - + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard: + + * Only recognized element symbols may be used. + * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. + * A space or parenthesis must separate each cluster of (element symbol + count). + * Where a group of elements is enclosed in parentheses, the multiplier for the + group must follow the closing parentheses. That is, all element and group + multipliers are assumed to be printed as subscripted numbers. + * Unless the elements are ordered in a manner that corresponds to their chemical + structure, the order of the elements within any group or moiety depends on + whether or not carbon is present. + * If carbon is present, the order should be: + + - C, then H, then the other elements in alphabetical order of their symbol. + - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. + + * This is the *Hill* system used by Chemical Abstracts. + DEBUG - ===== FIELD (//entry/sample/depends_on): DEBUG - value: b'/entry/sample/transformations/corrected_phi' DEBUG - classpath: ['NXentry', 'NXsample', 'NX_CHAR'] @@ -3521,12 +3521,12 @@ NXsample.nxdl.xml:/depends_on DEBUG - <> DEBUG - documentation (NXsample.nxdl.xml:/depends_on): DEBUG - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. DEBUG - ===== FIELD (//entry/sample/description): DEBUG - value: b'MoTe2' @@ -3536,8 +3536,8 @@ NXsample.nxdl.xml:/description DEBUG - <> DEBUG - documentation (NXsample.nxdl.xml:/description): DEBUG - - Description of the sample - + Description of the sample + DEBUG - ===== FIELD (//entry/sample/gas_pressure): DEBUG - value: 4.5599999999999996e-11 DEBUG - classpath: ['NXentry', 'NXsample', 'NX_FLOAT'] @@ -3562,7 +3562,9 @@ DEBUG - <> DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/SAMPLE/name): DEBUG - DEBUG - documentation (NXsample.nxdl.xml:/name): -DEBUG - Descriptive name of sample +DEBUG - + Descriptive name of sample + DEBUG - ===== FIELD (//entry/sample/preparation_date): DEBUG - value: b'2019-05-22T14:00:00+00:00' DEBUG - classpath: ['NXentry', 'NXsample', 'NX_DATE_TIME'] @@ -3576,7 +3578,9 @@ DEBUG - annealing). DEBUG - documentation (NXsample.nxdl.xml:/preparation_date): -DEBUG - Date of preparation of the sample +DEBUG - + Date of preparation of the sample + DEBUG - ===== GROUP (//entry/sample/preparation_description [NXmpes::/NXentry/NXsample/NXnote]): DEBUG - classpath: ['NXentry', 'NXsample', 'NXnote'] DEBUG - classes: @@ -3675,10 +3679,10 @@ DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/SAMPLE/situation): DEBUG - DEBUG - documentation (NXsample.nxdl.xml:/situation): DEBUG - - The atmosphere will be one of the components, which is where - its details will be stored; the relevant components will be - indicated by the entry in the sample_component member. - + The atmosphere will be one of the components, which is where + its details will be stored; the relevant components will be + indicated by the entry in the sample_component member. + DEBUG - ===== FIELD (//entry/sample/temperature): DEBUG - value: 23.050763803680983 DEBUG - classpath: ['NXentry', 'NXsample', 'NX_FLOAT'] @@ -3694,7 +3698,9 @@ DEBUG - /entry/instrument/manipulator/sample_temperature. DEBUG - documentation (NXsample.nxdl.xml:/temperature): -DEBUG - Sample temperature. This could be a scanned variable +DEBUG - + Sample temperature. This could be a scanned variable + DEBUG - ===== ATTRS (//entry/sample/temperature@units) DEBUG - value: K DEBUG - classpath: ['NXentry', 'NXsample', 'NX_FLOAT'] @@ -3711,10 +3717,10 @@ NXtransformations.nxdl.xml: DEBUG - <> DEBUG - documentation (NXsample.nxdl.xml:/TRANSFORMATIONS): DEBUG - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. DEBUG - documentation (NXtransformations.nxdl.xml:): DEBUG - diff --git a/tests/data/nexus/Ref_nexus_test.log b/tests/data/nexus/Ref_nexus_test.log index 0b9f8bebd..9bd98dd5b 100644 --- a/tests/data/nexus/Ref_nexus_test.log +++ b/tests/data/nexus/Ref_nexus_test.log @@ -1706,12 +1706,12 @@ DEBUG - documentation (NXentry.nxdl.xml:/SAMPLE): DEBUG - DEBUG - documentation (NXsample.nxdl.xml:): DEBUG - - Any information on the sample. - - This could include scanned variables that - are associated with one of the data dimensions, e.g. the magnetic field, or - logged data, e.g. monitored temperature vs elapsed time. - + Any information on the sample. + + This could include scanned variables that + are associated with one of the data dimensions, e.g. the magnetic field, or + logged data, e.g. monitored temperature vs elapsed time. + DEBUG - ===== ATTRS (//entry/sample@NX_class) DEBUG - value: NXsample DEBUG - classpath: ['NXentry', 'NXsample'] @@ -1766,7 +1766,9 @@ DEBUG - <> DEBUG - documentation (NXarpes.nxdl.xml:/ENTRY/SAMPLE/name): DEBUG - Descriptive name of sample DEBUG - documentation (NXsample.nxdl.xml:/name): -DEBUG - Descriptive name of sample +DEBUG - + Descriptive name of sample + DEBUG - ===== FIELD (//entry/sample/preparation_method): DEBUG - value: b'in-vacuum cleave' DEBUG - classpath: ['NXentry', 'NXsample'] @@ -1779,7 +1781,9 @@ DEBUG - classes: NXsample.nxdl.xml:/pressure DEBUG - <> DEBUG - documentation (NXsample.nxdl.xml:/pressure): -DEBUG - Applied pressure +DEBUG - + Applied pressure + DEBUG - ===== ATTRS (//entry/sample/pressure@units) DEBUG - value: mbar DEBUG - classpath: ['NXentry', 'NXsample', 'NX_FLOAT'] @@ -1829,7 +1833,9 @@ DEBUG - classes: NXsample.nxdl.xml:/thickness DEBUG - <> DEBUG - documentation (NXsample.nxdl.xml:/thickness): -DEBUG - sample thickness +DEBUG - + sample thickness + DEBUG - ===== ATTRS (//entry/sample/thickness@units) DEBUG - value: mm DEBUG - classpath: ['NXentry', 'NXsample', 'NX_FLOAT'] From 185482fd06d32dbfc6a480e8bb5c4b75018d6b3f Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Thu, 31 Aug 2023 17:04:18 +0200 Subject: [PATCH 15/18] mpes writing checks for a reference length --- tests/dataconverter/test_convert.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/dataconverter/test_convert.py b/tests/dataconverter/test_convert.py index f6702bf01..7c52dd95a 100644 --- a/tests/dataconverter/test_convert.py +++ b/tests/dataconverter/test_convert.py @@ -203,7 +203,7 @@ def test_mpes_writing(tmp_path): encoding='utf-8' ) as logfile: ref_log = logfile.readlines() - assert log == ref_log + assert len(log) == len(ref_log) def test_eln_data(tmp_path): From 6dfa9ba0a8672e26f038a561801ad64681144070 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Thu, 31 Aug 2023 17:09:49 +0200 Subject: [PATCH 16/18] Tested apm and em examples, ok --- examples/apm/Write.NXapm.Example.1.ipynb | 22 +++++++++---------- .../em_nion/Write.NXem_nion.Example.1.ipynb | 4 ++-- .../em_om/Write.NXem_ebsd.Example.1.ipynb | 12 +++++----- .../em_spctrscpy/Write.NXem.Example.1.ipynb | 4 ++-- 4 files changed, 21 insertions(+), 21 deletions(-) diff --git a/examples/apm/Write.NXapm.Example.1.ipynb b/examples/apm/Write.NXapm.Example.1.ipynb index 43b04a818..cb11f3c41 100644 --- a/examples/apm/Write.NXapm.Example.1.ipynb +++ b/examples/apm/Write.NXapm.Example.1.ipynb @@ -224,16 +224,16 @@ "input_recon_file_name = [\"Si.apt\",\n", " \"Si.epos\",\n", " \"Si.pos\",\n", - " \"R31_06365-v02.pos\",\n", - " \"R18_58152-v02.epos\",\n", - " \"70_50_50.apt\"]\n", + "# \"R31_06365-v02.pos\",\n", + "# \"R18_58152-v02.epos\",\n", + "# \"70_50_50.apt\"]\n", "# \"R56_01769-v01.pos\"]\n", "input_range_file_name = [\"Si.RRNG\",\n", " \"Si.RNG\",\n", " \"Si.RNG\",\n", - " \"R31_06365-v02.rrng\",\n", - " \"R31_06365-v02.rrng\",\n", - " \"R31_06365-v02.rrng\"]\n", + "# \"R31_06365-v02.rrng\",\n", + "# \"R31_06365-v02.rrng\",\n", + "# \"R31_06365-v02.rrng\"]\n", "# \"R56_01769.rng.fig.txt\"]\n", "output_file_name = [\"apm.case1.nxs\",\n", " \"apm.case2.nxs\",\n", @@ -241,7 +241,7 @@ " \"apm.case4.nxs\",\n", " \"apm.case5.nxs\",\n", " \"apm.case6.nxs\"]\n", - "for case_id in np.arange(0, 3 + 1):\n", + "for case_id in np.arange(0, 3):\n", " ELN = eln_data_file_name[0]\n", " OASIS = deployment_specific[0]\n", " INPUT_RECON = input_recon_file_name[case_id]\n", @@ -275,7 +275,7 @@ "outputs": [], "source": [ "# H5Web(OUTPUT)\n", - "H5Web(\"apm.case1.nxs\")" + "H5Web(\"apm.case3.nxs\")" ] }, { @@ -484,7 +484,7 @@ }, "outputs": [], "source": [ - "# ! dataconverter --reader apm --nxdl NXapm --input-file synthesize1 --output apm.case0.nxs" + "! dataconverter --reader apm --nxdl NXapm --input-file synthesize1 --output apm.case0.nxs" ] }, { @@ -515,7 +515,7 @@ "metadata": {}, "source": [ "### Contact person for the apm reader and related examples in FAIRmat:\n", - "Markus Kühbach, 2023/07/20
\n", + "Markus Kühbach, 2023/08/31
\n", "\n", "### Funding\n", "FAIRmat is a consortium on research data management which is part of the German NFDI.
\n", @@ -546,7 +546,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.9.12" + "version": "3.10.12" } }, "nbformat": 4, diff --git a/examples/em_nion/Write.NXem_nion.Example.1.ipynb b/examples/em_nion/Write.NXem_nion.Example.1.ipynb index 452f1d2c3..0d48dea69 100644 --- a/examples/em_nion/Write.NXem_nion.Example.1.ipynb +++ b/examples/em_nion/Write.NXem_nion.Example.1.ipynb @@ -248,7 +248,7 @@ "metadata": {}, "source": [ "### Contact person for the em_nion reader and related examples in FAIRmat:\n", - "Markus Kühbach, 2023/07/20
\n", + "Markus Kühbach, 2023/08/31
\n", "\n", "### Funding\n", "FAIRmat is a consortium on research data management which is part of the German NFDI.
\n", @@ -279,7 +279,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.9.12" + "version": "3.10.12" } }, "nbformat": 4, diff --git a/examples/em_om/Write.NXem_ebsd.Example.1.ipynb b/examples/em_om/Write.NXem_ebsd.Example.1.ipynb index 849da865f..7f5afeb6e 100644 --- a/examples/em_om/Write.NXem_ebsd.Example.1.ipynb +++ b/examples/em_om/Write.NXem_ebsd.Example.1.ipynb @@ -307,10 +307,10 @@ "source": [ "# H5Web(OUTPUT)\n", "H5Web(\"em_om.case0.nxs\")\n", - "H5Web(\"em_om.case1.nxs\")\n", - "H5Web(\"em_om.case2.nxs\")\n", - "H5Web(\"em_om.case3e.nxs\")\n", - "H5Web(\"em_om.case4.nxs\")" + "# H5Web(\"em_om.case1.nxs\")\n", + "# H5Web(\"em_om.case2.nxs\")\n", + "# H5Web(\"em_om.case3e.nxs\")\n", + "# H5Web(\"em_om.case4.nxs\")" ] }, { @@ -340,7 +340,7 @@ "metadata": {}, "source": [ "### Contact person for the apm reader and related examples in FAIRmat:\n", - "Markus Kühbach, 2023/07/20
\n", + "Markus Kühbach, 2023/08/31
\n", "\n", "### Funding\n", "FAIRmat is a consortium on research data management which is part of the German NFDI.
\n", @@ -364,7 +364,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.9.12" + "version": "3.10.12" }, "vscode": { "interpreter": { diff --git a/examples/em_spctrscpy/Write.NXem.Example.1.ipynb b/examples/em_spctrscpy/Write.NXem.Example.1.ipynb index 80455b2c2..3b57b7f9f 100644 --- a/examples/em_spctrscpy/Write.NXem.Example.1.ipynb +++ b/examples/em_spctrscpy/Write.NXem.Example.1.ipynb @@ -305,7 +305,7 @@ "metadata": {}, "source": [ "### Contact person for the apm reader and related examples in FAIRmat:\n", - "Markus Kühbach, 2023/07/20
\n", + "Markus Kühbach, 2023/08/31
\n", "\n", "### Funding\n", "FAIRmat is a consortium on research data management which is part of the German NFDI.
\n", @@ -336,7 +336,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.9.12" + "version": "3.10.12" }, "vscode": { "interpreter": { From 6d8ccd0f7e2348f2b4454332a6ae631707fec22c Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Thu, 31 Aug 2023 18:09:19 +0200 Subject: [PATCH 17/18] Removed obsolete Ref_nexus_mpes test log file --- .../readers/mpes/Ref_nexus_mpes.log | 4480 ----------------- 1 file changed, 4480 deletions(-) delete mode 100644 tests/data/dataconverter/readers/mpes/Ref_nexus_mpes.log diff --git a/tests/data/dataconverter/readers/mpes/Ref_nexus_mpes.log b/tests/data/dataconverter/readers/mpes/Ref_nexus_mpes.log deleted file mode 100644 index 35c7fb42f..000000000 --- a/tests/data/dataconverter/readers/mpes/Ref_nexus_mpes.log +++ /dev/null @@ -1,4480 +0,0 @@ -DEBUG - ===== GROUP (//entry [NXmpes::/NXentry]): -DEBUG - classpath: ['NXentry'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY -NXentry.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY): -DEBUG - -DEBUG - documentation (NXentry.nxdl.xml:): -DEBUG - - (**required**) :ref:`NXentry` describes the measurement. - - The top-level NeXus group which contains all the data and associated - information that comprise a single measurement. - It is mandatory that there is at least one - group of this type in the NeXus file. -DEBUG - ===== ATTRS (//entry@NX_class) -DEBUG - value: NXentry -DEBUG - classpath: ['NXentry'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY -NXentry.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== ATTRS (//entry@default) -DEBUG - value: data -DEBUG - classpath: ['NXentry'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY -NXentry.nxdl.xml: -DEBUG - NXmpes.nxdl.xml:/ENTRY@default - [NX_CHAR] -DEBUG - NXentry.nxdl.xml:@default - [NX_CHAR] -DEBUG - documentation (NXentry.nxdl.xml:/default): -DEBUG - - .. index:: find the default plottable data - .. index:: plotting - .. index:: default attribute value - - Declares which :ref:`NXdata` group contains the data - to be shown by default. - It is used to resolve ambiguity when - one :ref:`NXdata` group exists. - The value :ref:`names ` a child group. If that group - itself has a ``default`` attribute, continue this chain until an - :ref:`NXdata` group is reached. - - For more information about how NeXus identifies the default - plottable data, see the - :ref:`Find Plottable Data, v3 ` - section. - -DEBUG - ===== FIELD (//entry/collection_time): -DEBUG - value: 2317.343 -DEBUG - classpath: ['NXentry', 'NX_FLOAT'] -DEBUG - classes: -NXentry.nxdl.xml:/collection_time -DEBUG - <> -DEBUG - documentation (NXentry.nxdl.xml:/collection_time): -DEBUG - - Time transpired actually collecting data i.e. taking out time when collection was - suspended due to e.g. temperature out of range - -DEBUG - ===== ATTRS (//entry/collection_time@units) -DEBUG - value: s -DEBUG - classpath: ['NXentry', 'NX_FLOAT'] -DEBUG - classes: -NXentry.nxdl.xml:/collection_time -DEBUG - NXentry.nxdl.xml:/collection_time@units [NX_TIME] -DEBUG - ===== GROUP (//entry/data [NXmpes::/NXentry/NXdata]): -DEBUG - classpath: ['NXentry', 'NXdata'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/DATA -NXentry.nxdl.xml:/DATA -NXdata.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/DATA): -DEBUG - -DEBUG - documentation (NXentry.nxdl.xml:/DATA): -DEBUG - - The data group - - .. note:: Before the NIAC2016 meeting [#]_, at least one - :ref:`NXdata` group was required in each :ref:`NXentry` group. - At the NIAC2016 meeting, it was decided to make :ref:`NXdata` - an optional group in :ref:`NXentry` groups for data files that - do not use an application definition. - It is recommended strongly that all NeXus data files provide - a NXdata group. - It is permissable to omit the NXdata group only when - defining the default plot is not practical or possible - from the available data. - - For example, neutron event data may not have anything that - makes a useful plot without extensive processing. - - Certain application definitions override this decision and - require an :ref:`NXdata` group - in the :ref:`NXentry` group. The ``minOccurs=0`` attribute - in the application definition will indicate the - :ref:`NXdata` group - is optional, otherwise, it is required. - - .. [#] NIAC2016: - https://www.nexusformat.org/NIAC2016.html, - https://github.com/nexusformat/NIAC/issues/16 - - -DEBUG - documentation (NXdata.nxdl.xml:): -DEBUG - - :ref:`NXdata` describes the plottable data and related dimension scales. - - .. index:: plotting - - It is strongly recommended that there is at least one :ref:`NXdata` - group in each :ref:`NXentry` group. - Note that the fields named ``AXISNAME`` and ``DATA`` - can be defined with different names. - (Upper case is used to indicate that the actual name is left to the user.) - The ``signal`` and ``axes`` attributes of the - ``data`` group define which items - are plottable data and which are *dimension scales*, respectively. - - :ref:`NXdata` is used to implement one of the basic motivations in NeXus, - to provide a default plot for the data of this :ref:`NXentry`. The actual data - might be stored in another group and (hard) linked to the :ref:`NXdata` group. - - * Each :ref:`NXdata` group will define one field as the default - plottable data. The value of the ``signal`` attribute names this field. - Additional fields may be used to describe the dimension scales and - uncertainities. - The ``auxiliary_signals`` attribute is a list of the other fields - to be plotted with the ``signal`` data. - * The plottable data may be of arbitrary rank up to a maximum - of ``NX_MAXRANK=32`` (for compatibility with backend file formats). - * The plottable data will be named as the value of - the group ``signal`` attribute, such as:: - - data:NXdata - @signal = "counts" - @axes = "mr" - @mr_indices = 0 - counts: float[100] --> the default dependent data - mr: float[100] --> the default independent data - - The field named in the ``signal`` attribute **must** exist, either - directly as a NeXus field or defined through a link. - - * The group ``axes`` attribute will name the - *dimension scale* associated with the plottable data. - - If available, the standard deviations of the data are to be - stored in a data set of the same rank and dimensions, with the name ``errors``. - - * For each data dimension, there should be a one-dimensional array - of the same length. - * These one-dimensional arrays are the *dimension scales* of the - data, *i.e*. the values of the independent variables at which the data - is measured, such as scattering angle or energy transfer. - - .. index:: link - .. index:: axes (attribute) - - The preferred method to associate each data dimension with - its respective dimension scale is to specify the field name - of each dimension scale in the group ``axes`` attribute as a string list. - Here is an example for a 2-D data set *data* plotted - against *time*, and *pressure*. (An additional *temperature* data set - is provided and could be selected as an alternate for the *pressure* axis.):: - - data_2d:NXdata - @signal="data" - @axes=["time", "pressure"] - @pressure_indices=1 - @temperature_indices=1 - @time_indices=0 - data: float[1000,20] - pressure: float[20] - temperature: float[20] - time: float[1000] - - .. rubric:: Old methods to identify the plottable data - - There are two older methods of associating - each data dimension to its respective dimension scale. - Both are now out of date and - should not be used when writing new data files. - However, client software should expect to see data files - written with any of these methods. - - * One method uses the ``axes`` - attribute to specify the names of each *dimension scale*. - - * The oldest method uses the ``axis`` attribute on each - *dimension scale* to identify - with an integer the axis whose value is the number of the dimension. - - .. index: !plot; axis label - plot, axis units - units - dimension scale - - Each axis of the plot may be labeled with information from the - dimension scale for that axis. The optional ``@long_name`` attribute - is provided as the axis label default. If ``@long_name`` is not - defined, then use the name of the dimension scale. A ``@units`` attribute, - if available, may be added to the axis label for further description. - See the section :ref:`Design-Units` for more information. - - .. index: !plot; axis title - - The optional ``title`` field, if available, provides a suggested - title for the plot. If no ``title`` field is found in the :ref:`NXdata` - group, look for a ``title`` field in the parent :ref:`NXentry` group, - with a fallback to displaying the path to the :ref:`NXdata` group. - - NeXus is about how to find and annotate the data to be plotted - but not to describe how the data is to be plotted. - (https://www.nexusformat.org/NIAC2018Minutes.html#nxdata-plottype--attribute) - -DEBUG - ===== ATTRS (//entry/data@NX_class) -DEBUG - value: NXdata -DEBUG - classpath: ['NXentry', 'NXdata'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/DATA -NXentry.nxdl.xml:/DATA -NXdata.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== ATTRS (//entry/data@axes) -DEBUG - value: ['kx' 'ky' 'energy' 'delay'] -DEBUG - classpath: ['NXentry', 'NXdata'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/DATA -NXentry.nxdl.xml:/DATA -NXdata.nxdl.xml: -DEBUG - NXdata.nxdl.xml:@axes - [NX_CHAR] -DEBUG - <> -DEBUG - documentation (NXdata.nxdl.xml:/axes): -DEBUG - - .. index:: plotting - - Array of strings holding the :ref:`names ` of - the independent data fields used in the default plot for all of - the dimensions of the :ref:`signal ` - as well as any :ref:`auxiliary signals `. - - One name is provided for every dimension in the *signal* or *auxiliary signal* fields. - - The *axes* values are the names of fields or links that *must* exist and be direct - children of this NXdata group. - - An axis slice is specified using a field named ``AXISNAME_indices`` - as described below (where the text shown here as ``AXISNAME`` is to be - replaced by the actual field name). - - When no default axis is available for a particular dimension - of the plottable data, use a "." in that position. - Such as:: - - @axes=["time", ".", "."] - - Since there are three items in the list, the *signal* field - must be a three-dimensional array (rank=3). The first dimension - is described by the values of a one-dimensional array named ``time`` - while the other two dimensions have no fields to be used as dimension scales. - - See examples provided on the NeXus wiki: - https://www.nexusformat.org/2014_axes_and_uncertainties.html - - If there are no axes at all (such as with a stack of images), - the axes attribute can be omitted. - -DEBUG - ===== ATTRS (//entry/data@delay_indices) -DEBUG - value: 3 -DEBUG - classpath: ['NXentry', 'NXdata'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/DATA -NXentry.nxdl.xml:/DATA -NXdata.nxdl.xml: -DEBUG - @delay_indices - IS NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/data@energy_indices) -DEBUG - value: 2 -DEBUG - classpath: ['NXentry', 'NXdata'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/DATA -NXentry.nxdl.xml:/DATA -NXdata.nxdl.xml: -DEBUG - @energy_indices - IS NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/data@kx_indices) -DEBUG - value: 0 -DEBUG - classpath: ['NXentry', 'NXdata'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/DATA -NXentry.nxdl.xml:/DATA -NXdata.nxdl.xml: -DEBUG - @kx_indices - IS NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/data@ky_indices) -DEBUG - value: 1 -DEBUG - classpath: ['NXentry', 'NXdata'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/DATA -NXentry.nxdl.xml:/DATA -NXdata.nxdl.xml: -DEBUG - @ky_indices - IS NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/data@signal) -DEBUG - value: data -DEBUG - classpath: ['NXentry', 'NXdata'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/DATA -NXentry.nxdl.xml:/DATA -NXdata.nxdl.xml: -DEBUG - NXmpes.nxdl.xml:/ENTRY/DATA@signal - [NX_CHAR] -DEBUG - <> -DEBUG - enumeration (NXmpes.nxdl.xml:/ENTRY/DATA/signal): -DEBUG - -> data -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/DATA/signal): -DEBUG - -DEBUG - NXdata.nxdl.xml:@signal - [NX_CHAR] -DEBUG - documentation (NXdata.nxdl.xml:/signal): -DEBUG - - .. index:: find the default plottable data - .. index:: plotting - .. index:: signal attribute value - - Declares which NeXus field is the default. - The value is the :ref:`name ` of the data field to be plotted. - This field or link *must* exist and be a direct child of this NXdata group. - - It is recommended (as of NIAC2014) to use this attribute - rather than adding a signal attribute to the field. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -DEBUG - ===== FIELD (//entry/data/data): -DEBUG - value: [[[1.14760e+04 1.64560e+04 1.55440e+04 1.48940e+04 1.08810e+04] ... -DEBUG - classpath: ['NXentry', 'NXdata', 'NX_NUMBER'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/DATA/data -NXdata.nxdl.xml:/DATA -DEBUG - <> -DEBUG - Dataset referenced as NXdata SIGNAL -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/DATA/data): -DEBUG - - 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. - -DEBUG - documentation (NXdata.nxdl.xml:/DATA): -DEBUG - - .. index:: plotting - - This field contains the data values to be used as the - NeXus *plottable data*. - Client is responsible for defining the dimensions of the data. - The name of this field may be changed to fit the circumstances. - Standard NeXus client tools will use the attributes to determine - how to use this field. - -DEBUG - ===== ATTRS (//entry/data/data@units) -DEBUG - value: counts -DEBUG - classpath: ['NXentry', 'NXdata', 'NX_NUMBER'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/DATA/data -NXdata.nxdl.xml:/DATA -DEBUG - NXmpes.nxdl.xml:/ENTRY/DATA/data@units [NX_ANY] -DEBUG - NXdata.nxdl.xml:/DATA@units - REQUIRED, but undefined unit category -DEBUG - ===== FIELD (//entry/data/delay): -DEBUG - value: [-2000. 125. 2250. 4375. 6500.] -DEBUG - classpath: ['NXentry', 'NXdata', 'NX_NUMBER'] -DEBUG - classes: -NXdata.nxdl.xml:/AXISNAME -DEBUG - <> -DEBUG - Dataset referenced as NXdata AXIS #3 -DEBUG - documentation (NXdata.nxdl.xml:/AXISNAME): -DEBUG - - Dimension scale defining an axis of the data. - Client is responsible for defining the dimensions of the data. - The name of this field may be changed to fit the circumstances. - Standard NeXus client tools will use the attributes to determine - how to use this field. - -DEBUG - ===== ATTRS (//entry/data/delay@units) -DEBUG - value: ps -DEBUG - classpath: ['NXentry', 'NXdata', 'NX_NUMBER'] -DEBUG - classes: -NXdata.nxdl.xml:/AXISNAME -DEBUG - NXdata.nxdl.xml:/AXISNAME@units - REQUIRED, but undefined unit category -DEBUG - ===== FIELD (//entry/data/energy): -DEBUG - value: [-4. -3.44444444 -2.88888889 -2.33333333 -1.77777778 -1.22222222 ... -DEBUG - classpath: ['NXentry', 'NXdata', 'NX_NUMBER'] -DEBUG - classes: -NXdata.nxdl.xml:/AXISNAME -DEBUG - <> -DEBUG - Dataset referenced as NXdata AXIS #2 -DEBUG - documentation (NXdata.nxdl.xml:/AXISNAME): -DEBUG - - Dimension scale defining an axis of the data. - Client is responsible for defining the dimensions of the data. - The name of this field may be changed to fit the circumstances. - Standard NeXus client tools will use the attributes to determine - how to use this field. - -DEBUG - ===== ATTRS (//entry/data/energy@units) -DEBUG - value: eV -DEBUG - classpath: ['NXentry', 'NXdata', 'NX_NUMBER'] -DEBUG - classes: -NXdata.nxdl.xml:/AXISNAME -DEBUG - NXdata.nxdl.xml:/AXISNAME@units - REQUIRED, but undefined unit category -DEBUG - ===== FIELD (//entry/data/kx): -DEBUG - value: [-1.5 -1.16666667 -0.83333333 -0.5 -0.16666667 0.16666667 ... -DEBUG - classpath: ['NXentry', 'NXdata', 'NX_NUMBER'] -DEBUG - classes: -NXdata.nxdl.xml:/AXISNAME -DEBUG - <> -DEBUG - Dataset referenced as NXdata AXIS #0 -DEBUG - documentation (NXdata.nxdl.xml:/AXISNAME): -DEBUG - - Dimension scale defining an axis of the data. - Client is responsible for defining the dimensions of the data. - The name of this field may be changed to fit the circumstances. - Standard NeXus client tools will use the attributes to determine - how to use this field. - -DEBUG - ===== ATTRS (//entry/data/kx@units) -DEBUG - value: 1/A -DEBUG - classpath: ['NXentry', 'NXdata', 'NX_NUMBER'] -DEBUG - classes: -NXdata.nxdl.xml:/AXISNAME -DEBUG - NXdata.nxdl.xml:/AXISNAME@units - REQUIRED, but undefined unit category -DEBUG - ===== FIELD (//entry/data/ky): -DEBUG - value: [-1.5 -1.16666667 -0.83333333 -0.5 -0.16666667 0.16666667 ... -DEBUG - classpath: ['NXentry', 'NXdata', 'NX_NUMBER'] -DEBUG - classes: -NXdata.nxdl.xml:/AXISNAME -DEBUG - <> -DEBUG - Dataset referenced as NXdata AXIS #1 -DEBUG - documentation (NXdata.nxdl.xml:/AXISNAME): -DEBUG - - Dimension scale defining an axis of the data. - Client is responsible for defining the dimensions of the data. - The name of this field may be changed to fit the circumstances. - Standard NeXus client tools will use the attributes to determine - how to use this field. - -DEBUG - ===== ATTRS (//entry/data/ky@units) -DEBUG - value: 1/A -DEBUG - classpath: ['NXentry', 'NXdata', 'NX_NUMBER'] -DEBUG - classes: -NXdata.nxdl.xml:/AXISNAME -DEBUG - NXdata.nxdl.xml:/AXISNAME@units - REQUIRED, but undefined unit category -DEBUG - ===== FIELD (//entry/definition): -DEBUG - value: b'NXmpes' -DEBUG - classpath: ['NXentry', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/definition -NXentry.nxdl.xml:/definition -DEBUG - <> -DEBUG - enumeration (NXmpes.nxdl.xml:/ENTRY/definition): -DEBUG - -> NXmpes -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/definition): -DEBUG - -DEBUG - documentation (NXentry.nxdl.xml:/definition): -DEBUG - - (alternate use: see same field in :ref:`NXsubentry` for preferred) - - Official NeXus NXDL schema to which this entry conforms which must be - the name of the NXDL file (case sensitive without the file extension) - that the NXDL schema is defined in. - - For example the ``definition`` field for a file that conformed to the - *NXarpes.nxdl.xml* definition must contain the string **NXarpes**. - - This field is provided so that :ref:`NXentry` can be the overlay position - in a NeXus data file for an application definition and its - set of groups, fields, and attributes. - - *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. - -DEBUG - ===== ATTRS (//entry/definition@version) -DEBUG - value: None -DEBUG - classpath: ['NXentry', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/definition -NXentry.nxdl.xml:/definition -DEBUG - NXmpes.nxdl.xml:/ENTRY/definition@version - [NX_CHAR] -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/definition/version): -DEBUG - -DEBUG - NXentry.nxdl.xml:/definition@version - [NX_CHAR] -DEBUG - documentation (NXentry.nxdl.xml:/definition/version): -DEBUG - NXDL version number -DEBUG - ===== FIELD (//entry/duration): -DEBUG - value: 2317 -DEBUG - classpath: ['NXentry', 'NX_INT'] -DEBUG - classes: -NXentry.nxdl.xml:/duration -DEBUG - <> -DEBUG - documentation (NXentry.nxdl.xml:/duration): -DEBUG - Duration of measurement -DEBUG - ===== ATTRS (//entry/duration@units) -DEBUG - value: s -DEBUG - classpath: ['NXentry', 'NX_INT'] -DEBUG - classes: -NXentry.nxdl.xml:/duration -DEBUG - NXentry.nxdl.xml:/duration@units [NX_TIME] -DEBUG - ===== FIELD (//entry/end_time): -DEBUG - value: b'2019-05-23T18:52:32+00:00' -DEBUG - classpath: ['NXentry', 'NX_DATE_TIME'] -DEBUG - classes: -NXentry.nxdl.xml:/end_time -DEBUG - <> -DEBUG - documentation (NXentry.nxdl.xml:/end_time): -DEBUG - Ending time of measurement -DEBUG - ===== FIELD (//entry/entry_identifier): -DEBUG - value: b'2019/2019_05/2019_05_23/Scan005' -DEBUG - classpath: ['NXentry', 'NX_CHAR'] -DEBUG - classes: -NXentry.nxdl.xml:/entry_identifier -DEBUG - <> -DEBUG - documentation (NXentry.nxdl.xml:/entry_identifier): -DEBUG - unique identifier for the measurement, defined by the facility. -DEBUG - ===== FIELD (//entry/experiment_facility): -DEBUG - value: b'Time Resolved ARPES' -DEBUG - classpath: ['NXentry'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/experiment_institution): -DEBUG - value: b'Fritz Haber Institute - Max Planck Society' -DEBUG - classpath: ['NXentry'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/experiment_laboratory): -DEBUG - value: b'Clean Room 4' -DEBUG - classpath: ['NXentry'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== GROUP (//entry/instrument [NXmpes::/NXentry/NXinstrument]): -DEBUG - classpath: ['NXentry', 'NXinstrument'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT -NXentry.nxdl.xml:/INSTRUMENT -NXinstrument.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT): -DEBUG - -DEBUG - documentation (NXentry.nxdl.xml:/INSTRUMENT): -DEBUG - -DEBUG - documentation (NXinstrument.nxdl.xml:): -DEBUG - - Collection of the components of the instrument or beamline. - - Template of instrument descriptions comprising various beamline components. - Each component will also be a NeXus group defined by its distance from the - sample. Negative distances represent beamline components that are before the - sample while positive distances represent components that are after the sample. - This device allows the unique identification of beamline components in a way - that is valid for both reactor and pulsed instrumentation. - -DEBUG - ===== ATTRS (//entry/instrument@NX_class) -DEBUG - value: NXinstrument -DEBUG - classpath: ['NXentry', 'NXinstrument'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT -NXentry.nxdl.xml:/INSTRUMENT -NXinstrument.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== GROUP (//entry/instrument/beam [NXmpes::/NXentry/NXinstrument/NXbeam]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM -NXinstrument.nxdl.xml:/BEAM -NXbeam.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM): -DEBUG - -DEBUG - documentation (NXinstrument.nxdl.xml:/BEAM): -DEBUG - -DEBUG - documentation (NXbeam.nxdl.xml:): -DEBUG - - Properties of the neutron or X-ray beam at a given location. - - This group is intended to be referenced - by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. This group is - especially valuable in storing the results of instrument simulations in which it is useful - to specify the beam profile, time distribution etc. at each beamline component. Otherwise, - its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron - scattering by the sample, e.g., energy transfer, polarizations. Finally, There are cases where the beam is - considered as a beamline component and this group may be defined as a subgroup directly inside - :ref:`NXinstrument`, in which case it is recommended that the position of the beam is specified by an - :ref:`NXtransformations` group, unless the beam is at the origin (which is the sample). - - Note that incident_wavelength and related fields can be a scalar values or arrays, depending on the use case. - To support these use cases, the explicit dimensionality of these fields is not specified, but it can be inferred - by the presense of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam. - -DEBUG - ===== ATTRS (//entry/instrument/beam@NX_class) -DEBUG - value: NXbeam -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM -NXinstrument.nxdl.xml:/BEAM -NXbeam.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/beam/distance): -DEBUG - value: 0.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/distance -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/distance): -DEBUG - - Distance of the point of evaluation of the beam from the sample surface. - -DEBUG - ===== ATTRS (//entry/instrument/beam/distance@units) -DEBUG - value: mm -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/distance -DEBUG - NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/distance@units [NX_LENGTH] -DEBUG - ===== FIELD (//entry/instrument/beam/extent): -DEBUG - value: [ 80. 190.] -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/extent -DEBUG - <> -DEBUG - documentation (NXbeam.nxdl.xml:/extent): -DEBUG - - Size of the beam entering this component. Note this represents - a rectangular beam aperture, and values represent FWHM - -DEBUG - ===== ATTRS (//entry/instrument/beam/extent@units) -DEBUG - value: µm -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/extent -DEBUG - NXbeam.nxdl.xml:/extent@units [NX_LENGTH] -DEBUG - ===== FIELD (//entry/instrument/beam/incident_energy): -DEBUG - value: 21.7 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy -NXbeam.nxdl.xml:/incident_energy -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy): -DEBUG - -DEBUG - documentation (NXbeam.nxdl.xml:/incident_energy): -DEBUG - Energy carried by each particle of the beam on entering the beamline component -DEBUG - ===== ATTRS (//entry/instrument/beam/incident_energy@units) -DEBUG - value: eV -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy -NXbeam.nxdl.xml:/incident_energy -DEBUG - NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy@units [NX_ENERGY] -DEBUG - NXbeam.nxdl.xml:/incident_energy@units [NX_ENERGY] -DEBUG - ===== FIELD (//entry/instrument/beam/incident_energy_spread): -DEBUG - value: 0.11 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy_spread -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy_spread): -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/beam/incident_energy_spread@units) -DEBUG - value: eV -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy_spread -DEBUG - NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy_spread@units [NX_ENERGY] -DEBUG - ===== FIELD (//entry/instrument/beam/incident_polarization): -DEBUG - value: [1. 1. 0. 0.] -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_polarization -NXbeam.nxdl.xml:/incident_polarization -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_polarization): -DEBUG - -DEBUG - documentation (NXbeam.nxdl.xml:/incident_polarization): -DEBUG - Polarization vector on entering beamline component -DEBUG - ===== ATTRS (//entry/instrument/beam/incident_polarization@units) -DEBUG - value: V^2/mm^2 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_polarization -NXbeam.nxdl.xml:/incident_polarization -DEBUG - NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_polarization@units [NX_ANY] -DEBUG - NXbeam.nxdl.xml:/incident_polarization@units [NX_ANY] -DEBUG - ===== FIELD (//entry/instrument/beam/pulse_duration): -DEBUG - value: 20.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/beam/pulse_duration@units) -DEBUG - value: fs -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== GROUP (//entry/instrument/beam_pump [NXmpes::/NXentry/NXinstrument/NXbeam]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM -NXinstrument.nxdl.xml:/BEAM -NXbeam.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM): -DEBUG - -DEBUG - documentation (NXinstrument.nxdl.xml:/BEAM): -DEBUG - -DEBUG - documentation (NXbeam.nxdl.xml:): -DEBUG - - Properties of the neutron or X-ray beam at a given location. - - This group is intended to be referenced - by beamline component groups within the :ref:`NXinstrument` group or by the :ref:`NXsample` group. This group is - especially valuable in storing the results of instrument simulations in which it is useful - to specify the beam profile, time distribution etc. at each beamline component. Otherwise, - its most likely use is in the :ref:`NXsample` group in which it defines the results of the neutron - scattering by the sample, e.g., energy transfer, polarizations. Finally, There are cases where the beam is - considered as a beamline component and this group may be defined as a subgroup directly inside - :ref:`NXinstrument`, in which case it is recommended that the position of the beam is specified by an - :ref:`NXtransformations` group, unless the beam is at the origin (which is the sample). - - Note that incident_wavelength and related fields can be a scalar values or arrays, depending on the use case. - To support these use cases, the explicit dimensionality of these fields is not specified, but it can be inferred - by the presense of and shape of accompanying fields, such as incident_wavelength_weights for a polychromatic beam. - -DEBUG - ===== ATTRS (//entry/instrument/beam_pump@NX_class) -DEBUG - value: NXbeam -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM -NXinstrument.nxdl.xml:/BEAM -NXbeam.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/beam_pump/average_power): -DEBUG - value: 444.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/beam_pump/average_power@units) -DEBUG - value: mW -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/beam_pump/distance): -DEBUG - value: 0.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/distance -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/distance): -DEBUG - - Distance of the point of evaluation of the beam from the sample surface. - -DEBUG - ===== ATTRS (//entry/instrument/beam_pump/distance@units) -DEBUG - value: mm -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/distance -DEBUG - NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/distance@units [NX_LENGTH] -DEBUG - ===== FIELD (//entry/instrument/beam_pump/extent): -DEBUG - value: [155. 367.] -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/extent -DEBUG - <> -DEBUG - documentation (NXbeam.nxdl.xml:/extent): -DEBUG - - Size of the beam entering this component. Note this represents - a rectangular beam aperture, and values represent FWHM - -DEBUG - ===== ATTRS (//entry/instrument/beam_pump/extent@units) -DEBUG - value: µm -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/extent -DEBUG - NXbeam.nxdl.xml:/extent@units [NX_LENGTH] -DEBUG - ===== FIELD (//entry/instrument/beam_pump/fluence): -DEBUG - value: 1.3 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/beam_pump/fluence@units) -DEBUG - value: mJ/cm^2 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/beam_pump/incident_energy): -DEBUG - value: 1.2 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy -NXbeam.nxdl.xml:/incident_energy -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy): -DEBUG - -DEBUG - documentation (NXbeam.nxdl.xml:/incident_energy): -DEBUG - Energy carried by each particle of the beam on entering the beamline component -DEBUG - ===== ATTRS (//entry/instrument/beam_pump/incident_energy@units) -DEBUG - value: eV -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy -NXbeam.nxdl.xml:/incident_energy -DEBUG - NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy@units [NX_ENERGY] -DEBUG - NXbeam.nxdl.xml:/incident_energy@units [NX_ENERGY] -DEBUG - ===== FIELD (//entry/instrument/beam_pump/incident_energy_spread): -DEBUG - value: 0.05 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy_spread -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy_spread): -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/beam_pump/incident_energy_spread@units) -DEBUG - value: eV -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy_spread -DEBUG - NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_energy_spread@units [NX_ENERGY] -DEBUG - ===== FIELD (//entry/instrument/beam_pump/incident_polarization): -DEBUG - value: [1 1 0 0] -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_polarization -NXbeam.nxdl.xml:/incident_polarization -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_polarization): -DEBUG - -DEBUG - documentation (NXbeam.nxdl.xml:/incident_polarization): -DEBUG - Polarization vector on entering beamline component -DEBUG - ===== ATTRS (//entry/instrument/beam_pump/incident_polarization@units) -DEBUG - value: V^2/mm^2 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_NUMBER'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_polarization -NXbeam.nxdl.xml:/incident_polarization -DEBUG - NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/BEAM/incident_polarization@units [NX_ANY] -DEBUG - NXbeam.nxdl.xml:/incident_polarization@units [NX_ANY] -DEBUG - ===== FIELD (//entry/instrument/beam_pump/incident_wavelength): -DEBUG - value: 1030.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/incident_wavelength -DEBUG - <> -DEBUG - documentation (NXbeam.nxdl.xml:/incident_wavelength): -DEBUG - - In the case of a monochromatic beam this is the scalar - wavelength. - - Several other use cases are permitted, depending on the - presence or absence of other incident_wavelength_X - fields. - - In the case of a polychromatic beam this is an array of - length **m** of wavelengths, with the relative weights - in ``incident_wavelength_weights``. - - In the case of a monochromatic beam that varies shot- - to-shot, this is an array of wavelengths, one for each - recorded shot. Here, ``incident_wavelength_weights`` and - incident_wavelength_spread are not set. - - In the case of a polychromatic beam that varies shot-to- - shot, this is an array of length **m** with the relative - weights in ``incident_wavelength_weights`` as a 2D array. - - In the case of a polychromatic beam that varies shot-to- - shot and where the channels also vary, this is a 2D array - of dimensions **nP** by **m** (slow to fast) with the - relative weights in ``incident_wavelength_weights`` as a 2D - array. - - Note, :ref:`variants ` are a good way - to represent several of these use cases in a single dataset, - e.g. if a calibrated, single-value wavelength value is - available along with the original spectrum from which it - was calibrated. - Wavelength on entering beamline component - -DEBUG - ===== ATTRS (//entry/instrument/beam_pump/incident_wavelength@units) -DEBUG - value: nm -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam', 'NX_FLOAT'] -DEBUG - classes: -NXbeam.nxdl.xml:/incident_wavelength -DEBUG - NXbeam.nxdl.xml:/incident_wavelength@units [NX_WAVELENGTH] -DEBUG - ===== FIELD (//entry/instrument/beam_pump/pulse_duration): -DEBUG - value: 140.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/beam_pump/pulse_duration@units) -DEBUG - value: fs -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/beam_pump/pulse_energy): -DEBUG - value: 0.889 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/beam_pump/pulse_energy@units) -DEBUG - value: µJ -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXbeam'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== GROUP (//entry/instrument/electronanalyser [NXmpes::/NXentry/NXinstrument/NXelectronanalyser]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER -NXelectronanalyser.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER): -DEBUG - -DEBUG - documentation (NXelectronanalyser.nxdl.xml:): -DEBUG - - Subclass of NXinstrument to describe a photoelectron analyser. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser@NX_class) -DEBUG - value: NXelectronanalyser -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER -NXelectronanalyser.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/COLLECTIONCOLUMN -NXelectronanalyser.nxdl.xml:/COLLECTIONCOLUMN -NXcollectioncolumn.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/COLLECTIONCOLUMN): -DEBUG - -DEBUG - documentation (NXelectronanalyser.nxdl.xml:/COLLECTIONCOLUMN): -DEBUG - - Describes the electron collection (spatial and momentum imaging) column - -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:): -DEBUG - - Subclass of NXelectronanalyser to describe the electron collection column of a - photoelectron analyser. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn@NX_class) -DEBUG - value: NXcollectioncolumn -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/COLLECTIONCOLUMN -NXelectronanalyser.nxdl.xml:/COLLECTIONCOLUMN -NXcollectioncolumn.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/contrast_aperture [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXaperture]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/COLLECTIONCOLUMN/contrast_aperture -NXcollectioncolumn.nxdl.xml:/APERTURE -NXaperture.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/COLLECTIONCOLUMN/contrast_aperture): -DEBUG - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:/APERTURE): -DEBUG - - The size and position of an aperture inserted in the column, e.g. field aperture - or contrast aperture - -DEBUG - documentation (NXaperture.nxdl.xml:): -DEBUG - A beamline aperture. This group is deprecated, use NXslit instead. -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/contrast_aperture@NX_class) -DEBUG - value: NXaperture -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/COLLECTIONCOLUMN/contrast_aperture -NXcollectioncolumn.nxdl.xml:/APERTURE -NXaperture.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/contrast_aperture/ca_m3 [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXaperture/ca_m3]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/contrast_aperture/ca_m3/value): -DEBUG - value: -11.49979350759219 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/contrast_aperture/ca_m3/value@units) -DEBUG - value: mm -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/contrast_aperture/shape): -DEBUG - value: b'open' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/contrast_aperture/size): -DEBUG - value: nan -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/contrast_aperture/size@units) -DEBUG - value: µm -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/extractor_current): -DEBUG - value: -0.1309711275510204 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NX_FLOAT'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/extractor_current -DEBUG - <> -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:/extractor_current): -DEBUG - - Current necessary to keep the extractor lens at a set voltage. Variations - indicate leakage, field emission or arc currents to the extractor lens. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/extractor_current@units) -DEBUG - value: µA -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NX_FLOAT'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/extractor_current -DEBUG - NXcollectioncolumn.nxdl.xml:/extractor_current@units [NX_CURRENT] -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/extractor_voltage): -DEBUG - value: 6000.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NX_FLOAT'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/extractor_voltage -DEBUG - <> -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:/extractor_voltage): -DEBUG - - Voltage applied to the extractor lens - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/extractor_voltage@units) -DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NX_FLOAT'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/extractor_voltage -DEBUG - NXcollectioncolumn.nxdl.xml:/extractor_voltage@units [NX_VOLTAGE] -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/field_aperture [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXaperture]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/COLLECTIONCOLUMN/field_aperture -NXcollectioncolumn.nxdl.xml:/APERTURE -NXaperture.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/COLLECTIONCOLUMN/field_aperture): -DEBUG - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:/APERTURE): -DEBUG - - The size and position of an aperture inserted in the column, e.g. field aperture - or contrast aperture - -DEBUG - documentation (NXaperture.nxdl.xml:): -DEBUG - A beamline aperture. This group is deprecated, use NXslit instead. -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/field_aperture@NX_class) -DEBUG - value: NXaperture -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/COLLECTIONCOLUMN/field_aperture -NXcollectioncolumn.nxdl.xml:/APERTURE -NXaperture.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/fa_m1 [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXaperture/fa_m1]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/fa_m1/value): -DEBUG - value: 3.749874153422982 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/fa_m1/value@units) -DEBUG - value: mm -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/fa_m2 [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXaperture/fa_m2]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/fa_m2/value): -DEBUG - value: -5.200156936301793 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/fa_m2/value@units) -DEBUG - value: mm -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/shape): -DEBUG - value: b'circle' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/size): -DEBUG - value: 200.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/field_aperture/size@units) -DEBUG - value: µm -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXaperture'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/lens_A [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXlens_em]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:/LENS_EM): -DEBUG - - Individual lenses in the collection column section - -DEBUG - documentation (NXlens_em.nxdl.xml:): -DEBUG - - 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 `_ - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_A@NX_class) -DEBUG - value: NXlens_em -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_A/name): -DEBUG - value: b'A' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_CHAR'] -DEBUG - classes: -NXlens_em.nxdl.xml:/name -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/name): -DEBUG - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_A/voltage): -DEBUG - value: 784.58 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/voltage): -DEBUG - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_A/voltage@units) -DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - NXlens_em.nxdl.xml:/voltage@units [NX_VOLTAGE] -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/lens_B [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXlens_em]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:/LENS_EM): -DEBUG - - Individual lenses in the collection column section - -DEBUG - documentation (NXlens_em.nxdl.xml:): -DEBUG - - 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 `_ - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_B@NX_class) -DEBUG - value: NXlens_em -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_B/name): -DEBUG - value: b'B' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_CHAR'] -DEBUG - classes: -NXlens_em.nxdl.xml:/name -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/name): -DEBUG - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_B/voltage): -DEBUG - value: 3253.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/voltage): -DEBUG - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_B/voltage@units) -DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - NXlens_em.nxdl.xml:/voltage@units [NX_VOLTAGE] -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/lens_C [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXlens_em]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:/LENS_EM): -DEBUG - - Individual lenses in the collection column section - -DEBUG - documentation (NXlens_em.nxdl.xml:): -DEBUG - - 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 `_ - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_C@NX_class) -DEBUG - value: NXlens_em -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_C/name): -DEBUG - value: b'C' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_CHAR'] -DEBUG - classes: -NXlens_em.nxdl.xml:/name -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/name): -DEBUG - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_C/voltage): -DEBUG - value: 752.07 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/voltage): -DEBUG - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_C/voltage@units) -DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - NXlens_em.nxdl.xml:/voltage@units [NX_VOLTAGE] -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/lens_D [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXlens_em]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:/LENS_EM): -DEBUG - - Individual lenses in the collection column section - -DEBUG - documentation (NXlens_em.nxdl.xml:): -DEBUG - - 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 `_ - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_D@NX_class) -DEBUG - value: NXlens_em -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_D/name): -DEBUG - value: b'D' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_CHAR'] -DEBUG - classes: -NXlens_em.nxdl.xml:/name -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/name): -DEBUG - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_D/voltage): -DEBUG - value: 682.18 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/voltage): -DEBUG - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_D/voltage@units) -DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - NXlens_em.nxdl.xml:/voltage@units [NX_VOLTAGE] -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/lens_E [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXlens_em]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:/LENS_EM): -DEBUG - - Individual lenses in the collection column section - -DEBUG - documentation (NXlens_em.nxdl.xml:): -DEBUG - - 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 `_ - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_E@NX_class) -DEBUG - value: NXlens_em -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_E/name): -DEBUG - value: b'E' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_CHAR'] -DEBUG - classes: -NXlens_em.nxdl.xml:/name -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/name): -DEBUG - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_E/voltage): -DEBUG - value: 200.93 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/voltage): -DEBUG - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_E/voltage@units) -DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - NXlens_em.nxdl.xml:/voltage@units [NX_VOLTAGE] -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/lens_F [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXlens_em]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:/LENS_EM): -DEBUG - - Individual lenses in the collection column section - -DEBUG - documentation (NXlens_em.nxdl.xml:): -DEBUG - - 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 `_ - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_F@NX_class) -DEBUG - value: NXlens_em -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_F/name): -DEBUG - value: b'F' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_CHAR'] -DEBUG - classes: -NXlens_em.nxdl.xml:/name -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/name): -DEBUG - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_F/voltage): -DEBUG - value: 68.557 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/voltage): -DEBUG - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_F/voltage@units) -DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - NXlens_em.nxdl.xml:/voltage@units [NX_VOLTAGE] -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/lens_Foc [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXlens_em]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:/LENS_EM): -DEBUG - - Individual lenses in the collection column section - -DEBUG - documentation (NXlens_em.nxdl.xml:): -DEBUG - - 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 `_ - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_Foc@NX_class) -DEBUG - value: NXlens_em -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_Foc/name): -DEBUG - value: b'Foc' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_CHAR'] -DEBUG - classes: -NXlens_em.nxdl.xml:/name -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/name): -DEBUG - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_Foc/voltage): -DEBUG - value: 158.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/voltage): -DEBUG - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_Foc/voltage@units) -DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - NXlens_em.nxdl.xml:/voltage@units [NX_VOLTAGE] -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/lens_G [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXlens_em]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:/LENS_EM): -DEBUG - - Individual lenses in the collection column section - -DEBUG - documentation (NXlens_em.nxdl.xml:): -DEBUG - - 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 `_ - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_G@NX_class) -DEBUG - value: NXlens_em -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_G/name): -DEBUG - value: b'G' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_CHAR'] -DEBUG - classes: -NXlens_em.nxdl.xml:/name -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/name): -DEBUG - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_G/voltage): -DEBUG - value: 30.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/voltage): -DEBUG - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_G/voltage@units) -DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - NXlens_em.nxdl.xml:/voltage@units [NX_VOLTAGE] -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/lens_H [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXlens_em]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:/LENS_EM): -DEBUG - - Individual lenses in the collection column section - -DEBUG - documentation (NXlens_em.nxdl.xml:): -DEBUG - - 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 `_ - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_H@NX_class) -DEBUG - value: NXlens_em -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_H/name): -DEBUG - value: b'H' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_CHAR'] -DEBUG - classes: -NXlens_em.nxdl.xml:/name -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/name): -DEBUG - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_H/voltage): -DEBUG - value: 30.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/voltage): -DEBUG - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_H/voltage@units) -DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - NXlens_em.nxdl.xml:/voltage@units [NX_VOLTAGE] -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/lens_I [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXlens_em]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:/LENS_EM): -DEBUG - - Individual lenses in the collection column section - -DEBUG - documentation (NXlens_em.nxdl.xml:): -DEBUG - - 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 `_ - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_I@NX_class) -DEBUG - value: NXlens_em -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_I/name): -DEBUG - value: b'I' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_CHAR'] -DEBUG - classes: -NXlens_em.nxdl.xml:/name -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/name): -DEBUG - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_I/voltage): -DEBUG - value: 44.5 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/voltage): -DEBUG - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_I/voltage@units) -DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - NXlens_em.nxdl.xml:/voltage@units [NX_VOLTAGE] -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/lens_UCA [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXlens_em]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:/LENS_EM): -DEBUG - - Individual lenses in the collection column section - -DEBUG - documentation (NXlens_em.nxdl.xml:): -DEBUG - - 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 `_ - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_UCA@NX_class) -DEBUG - value: NXlens_em -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_UCA/name): -DEBUG - value: b'UCA' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_CHAR'] -DEBUG - classes: -NXlens_em.nxdl.xml:/name -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/name): -DEBUG - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_UCA/voltage): -DEBUG - value: 1200.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/voltage): -DEBUG - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_UCA/voltage@units) -DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - NXlens_em.nxdl.xml:/voltage@units [NX_VOLTAGE] -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/collectioncolumn/lens_UFA [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXcollectioncolumn/NXlens_em]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:/LENS_EM): -DEBUG - - Individual lenses in the collection column section - -DEBUG - documentation (NXlens_em.nxdl.xml:): -DEBUG - - 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 `_ - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_UFA@NX_class) -DEBUG - value: NXlens_em -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/LENS_EM -NXlens_em.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_UFA/name): -DEBUG - value: b'UFA' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_CHAR'] -DEBUG - classes: -NXlens_em.nxdl.xml:/name -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/name): -DEBUG - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/lens_UFA/voltage): -DEBUG - value: 600.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - <> -DEBUG - documentation (NXlens_em.nxdl.xml:/voltage): -DEBUG - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/lens_UFA/voltage@units) -DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NXlens_em', 'NX_NUMBER'] -DEBUG - classes: -NXlens_em.nxdl.xml:/voltage -DEBUG - NXlens_em.nxdl.xml:/voltage@units [NX_VOLTAGE] -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/mode): -DEBUG - value: b'6kV_kmodem2.0_30VTOF_MoTe2_2340VMCP.sav' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/COLLECTIONCOLUMN/mode -NXcollectioncolumn.nxdl.xml:/mode -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/COLLECTIONCOLUMN/mode): -DEBUG - -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:/mode): -DEBUG - - Labelling of the lens setting in use. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/projection): -DEBUG - value: b'reciprocal' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/COLLECTIONCOLUMN/projection -NXcollectioncolumn.nxdl.xml:/projection -DEBUG - <> -DEBUG - enumeration (NXcollectioncolumn.nxdl.xml:/projection): -DEBUG - -> real -DEBUG - -> reciprocal -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/COLLECTIONCOLUMN/projection): -DEBUG - -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:/projection): -DEBUG - - The space projected in the angularly dispersive directions, real or reciprocal - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/scheme): -DEBUG - value: b'Momentum Microscope' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/COLLECTIONCOLUMN/scheme -NXcollectioncolumn.nxdl.xml:/scheme -DEBUG - <> -DEBUG - enumeration (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/COLLECTIONCOLUMN/scheme): -DEBUG - -> Standard -DEBUG - -> Angular dispersive -DEBUG - -> Selective area -DEBUG - -> Deflector -DEBUG - -> PEEM -DEBUG - -> Momentum Microscope -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/COLLECTIONCOLUMN/scheme): -DEBUG - - Scheme of the electron collection column. - -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:/scheme): -DEBUG - - Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum - microscope, etc. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/collectioncolumn/working_distance): -DEBUG - value: 4.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NX_FLOAT'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/working_distance -DEBUG - <> -DEBUG - documentation (NXcollectioncolumn.nxdl.xml:/working_distance): -DEBUG - - Distance between sample and detector entrance - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/collectioncolumn/working_distance@units) -DEBUG - value: mm -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXcollectioncolumn', 'NX_FLOAT'] -DEBUG - classes: -NXcollectioncolumn.nxdl.xml:/working_distance -DEBUG - NXcollectioncolumn.nxdl.xml:/working_distance@units [NX_LENGTH] -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/depends_on): -DEBUG - value: b'/entry/instrument/electronanalyser/transformations/trans_z' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NX_CHAR'] -DEBUG - classes: -NXelectronanalyser.nxdl.xml:/depends_on -DEBUG - <> -DEBUG - documentation (NXelectronanalyser.nxdl.xml:/depends_on): -DEBUG - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/description): -DEBUG - value: b'SPECS Metis 1000 Momentum Microscope' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/description -NXelectronanalyser.nxdl.xml:/description -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/description): -DEBUG - -DEBUG - documentation (NXelectronanalyser.nxdl.xml:/description): -DEBUG - - Free text description of the type of the detector - -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/detector [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXdetector]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/DETECTOR -NXelectronanalyser.nxdl.xml:/DETECTOR -NXdetector.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/DETECTOR): -DEBUG - -DEBUG - documentation (NXelectronanalyser.nxdl.xml:/DETECTOR): -DEBUG - - Describes the electron detector - -DEBUG - documentation (NXdetector.nxdl.xml:): -DEBUG - - A detector, detector bank, or multidetector. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/detector@NX_class) -DEBUG - value: NXdetector -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/DETECTOR -NXelectronanalyser.nxdl.xml:/DETECTOR -NXdetector.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/detector/amplifier_bias): -DEBUG - value: 30.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/detector/amplifier_bias@units) -DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/detector/amplifier_type): -DEBUG - value: b'MCP' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/DETECTOR/amplifier_type -DEBUG - <> -DEBUG - enumeration (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/DETECTOR/amplifier_type): -DEBUG - -> MCP -DEBUG - -> channeltron -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/DETECTOR/amplifier_type): -DEBUG - - Type of electron amplifier in the first amplification step. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/detector/amplifier_voltage): -DEBUG - value: 2340.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/detector/amplifier_voltage@units) -DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/detector/detector_type): -DEBUG - value: b'DLD' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/DETECTOR/detector_type -DEBUG - <> -DEBUG - enumeration (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/DETECTOR/detector_type): -DEBUG - -> DLD -DEBUG - -> Phosphor+CCD -DEBUG - -> Phosphor+CMOS -DEBUG - -> ECMOS -DEBUG - -> Anode -DEBUG - -> Multi-anode -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/DETECTOR/detector_type): -DEBUG - - Description of the detector type. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/detector/detector_voltage): -DEBUG - value: 399.99712810186986 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/detector/detector_voltage@units) -DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/detector/sensor_pixels): -DEBUG - value: [1800 1800] -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXdetector'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/energy_resolution): -DEBUG - value: 110.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NX_FLOAT'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/energy_resolution -NXelectronanalyser.nxdl.xml:/energy_resolution -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/energy_resolution): -DEBUG - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - -DEBUG - documentation (NXelectronanalyser.nxdl.xml:/energy_resolution): -DEBUG - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/energy_resolution@units) -DEBUG - value: meV -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NX_FLOAT'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/energy_resolution -NXelectronanalyser.nxdl.xml:/energy_resolution -DEBUG - NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/energy_resolution@units [NX_ENERGY] -DEBUG - NXelectronanalyser.nxdl.xml:/energy_resolution@units [NX_ENERGY] -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/energydispersion [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXenergydispersion]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXenergydispersion'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/ENERGYDISPERSION -NXelectronanalyser.nxdl.xml:/ENERGYDISPERSION -NXenergydispersion.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/ENERGYDISPERSION): -DEBUG - -DEBUG - documentation (NXelectronanalyser.nxdl.xml:/ENERGYDISPERSION): -DEBUG - - Describes the energy dispersion section - -DEBUG - documentation (NXenergydispersion.nxdl.xml:): -DEBUG - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/energydispersion@NX_class) -DEBUG - value: NXenergydispersion -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXenergydispersion'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/ENERGYDISPERSION -NXelectronanalyser.nxdl.xml:/ENERGYDISPERSION -NXenergydispersion.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/energydispersion/energy_scan_mode): -DEBUG - value: b'fixed' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXenergydispersion', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/ENERGYDISPERSION/energy_scan_mode -NXenergydispersion.nxdl.xml:/energy_scan_mode -DEBUG - <> -DEBUG - enumeration (NXenergydispersion.nxdl.xml:/energy_scan_mode): -DEBUG - -> fixed -DEBUG - -> sweep -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/ENERGYDISPERSION/energy_scan_mode): -DEBUG - -DEBUG - documentation (NXenergydispersion.nxdl.xml:/energy_scan_mode): -DEBUG - - Way of scanning the energy axis (fixed or sweep). - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/energydispersion/pass_energy): -DEBUG - value: 30.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXenergydispersion', 'NX_FLOAT'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/ENERGYDISPERSION/pass_energy -NXenergydispersion.nxdl.xml:/pass_energy -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/ENERGYDISPERSION/pass_energy): -DEBUG - -DEBUG - documentation (NXenergydispersion.nxdl.xml:/pass_energy): -DEBUG - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/energydispersion/pass_energy@units) -DEBUG - value: eV -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXenergydispersion', 'NX_FLOAT'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/ENERGYDISPERSION/pass_energy -NXenergydispersion.nxdl.xml:/pass_energy -DEBUG - NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/ENERGYDISPERSION/pass_energy@units [NX_ENERGY] -DEBUG - NXenergydispersion.nxdl.xml:/pass_energy@units [NX_ENERGY] -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/energydispersion/scheme): -DEBUG - value: b'tof' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXenergydispersion', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/ENERGYDISPERSION/scheme -NXenergydispersion.nxdl.xml:/scheme -DEBUG - <> -DEBUG - enumeration (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/ENERGYDISPERSION/scheme): -DEBUG - -> tof -DEBUG - -> hemispherical -DEBUG - -> double hemispherical -DEBUG - -> cylindrical mirror -DEBUG - -> display mirror -DEBUG - -> retarding grid -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/ENERGYDISPERSION/scheme): -DEBUG - -DEBUG - documentation (NXenergydispersion.nxdl.xml:/scheme): -DEBUG - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/energydispersion/tof_distance): -DEBUG - value: 0.9 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXenergydispersion', 'NX_FLOAT'] -DEBUG - classes: -NXenergydispersion.nxdl.xml:/tof_distance -DEBUG - <> -DEBUG - documentation (NXenergydispersion.nxdl.xml:/tof_distance): -DEBUG - - Length of the tof drift electrode - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/energydispersion/tof_distance@units) -DEBUG - value: m -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXenergydispersion', 'NX_FLOAT'] -DEBUG - classes: -NXenergydispersion.nxdl.xml:/tof_distance -DEBUG - NXenergydispersion.nxdl.xml:/tof_distance@units [NX_LENGTH] -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/fast_axes): -DEBUG - value: [b'kx' b'ky' b'E'] -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/fast_axes -NXelectronanalyser.nxdl.xml:/fast_axes -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/fast_axes): -DEBUG - -DEBUG - documentation (NXelectronanalyser.nxdl.xml:/fast_axes): -DEBUG - - 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. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/momentum_resolution): -DEBUG - value: 0.08 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NX_FLOAT'] -DEBUG - classes: -NXelectronanalyser.nxdl.xml:/momentum_resolution -DEBUG - <> -DEBUG - documentation (NXelectronanalyser.nxdl.xml:/momentum_resolution): -DEBUG - - Momentum resolution of the electron analyser (FWHM) - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/momentum_resolution@units) -DEBUG - value: 1/angstrom -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NX_FLOAT'] -DEBUG - classes: -NXelectronanalyser.nxdl.xml:/momentum_resolution -DEBUG - NXelectronanalyser.nxdl.xml:/momentum_resolution@units [NX_WAVENUMBER] -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/slow_axes): -DEBUG - value: b'delay' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/slow_axes -NXelectronanalyser.nxdl.xml:/slow_axes -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/ELECTRONANALYSER/slow_axes): -DEBUG - -DEBUG - documentation (NXelectronanalyser.nxdl.xml:/slow_axes): -DEBUG - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/spatial_resolution): -DEBUG - value: 10.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NX_FLOAT'] -DEBUG - classes: -NXelectronanalyser.nxdl.xml:/spatial_resolution -DEBUG - <> -DEBUG - documentation (NXelectronanalyser.nxdl.xml:/spatial_resolution): -DEBUG - - Spatial resolution of the electron analyser (Airy disk radius) - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/spatial_resolution@units) -DEBUG - value: µm -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NX_FLOAT'] -DEBUG - classes: -NXelectronanalyser.nxdl.xml:/spatial_resolution -DEBUG - NXelectronanalyser.nxdl.xml:/spatial_resolution@units [NX_LENGTH] -DEBUG - ===== GROUP (//entry/instrument/electronanalyser/transformations [NXmpes::/NXentry/NXinstrument/NXelectronanalyser/NXtransformations]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXtransformations'] -DEBUG - classes: -NXelectronanalyser.nxdl.xml:/TRANSFORMATIONS -NXtransformations.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXelectronanalyser.nxdl.xml:/TRANSFORMATIONS): -DEBUG - - 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. - -DEBUG - documentation (NXtransformations.nxdl.xml:): -DEBUG - - Collection of axis-based translations and rotations to describe a geometry. - May also contain axes that do not move and therefore do not have a transformation - type specified, but are useful in understanding coordinate frames within which - transformations are done, or in documenting important directions, such as the - direction of gravity. - - A nested sequence of transformations lists the translation and rotation steps - needed to describe the position and orientation of any movable or fixed device. - - There will be one or more transformations (axes) defined by one or more fields - for each transformation. Transformations can also be described by NXlog groups when - the values change with time. The all-caps name ``AXISNAME`` designates the - particular axis generating a transformation (e.g. a rotation axis or a translation - axis or a general axis). The attribute ``units="NX_TRANSFORMATION"`` designates the - units will be appropriate to the ``transformation_type`` attribute: - - * ``NX_LENGTH`` for ``translation`` - * ``NX_ANGLE`` for ``rotation`` - * ``NX_UNITLESS`` for axes for which no transformation type is specified - - This class will usually contain all axes of a sample stage or goniometer or - a detector. The NeXus default McSTAS coordinate frame is assumed, but additional - useful coordinate axes may be defined by using axes for which no transformation - type has been specified. - - The entry point (``depends_on``) will be outside of this class and point to a - field in here. Following the chain may also require following ``depends_on`` - links to transformations outside, for example to a common base table. If - a relative path is given, it is relative to the group enclosing the ``depends_on`` - specification. - - For a chain of three transformations, where :math:`T_1` depends on :math:`T_2` - and that in turn depends on :math:`T_3`, the final transformation :math:`T_f` is - - .. math:: T_f = T_3 T_2 T_1 - - In explicit terms, the transformations are a subset of affine transformations - expressed as 4x4 matrices that act on homogeneous coordinates, :math:`w=(x,y,z,1)^T`. - - For rotation and translation, - - .. math:: T_r &= \begin{pmatrix} R & o \\ 0_3 & 1 \end{pmatrix} \\ T_t &= \begin{pmatrix} I_3 & t + o \\ 0_3 & 1 \end{pmatrix} - - where :math:`R` is the usual 3x3 rotation matrix, :math:`o` is an offset vector, - :math:`0_3` is a row of 3 zeros, :math:`I_3` is the 3x3 identity matrix and - :math:`t` is the translation vector. - - :math:`o` is given by the ``offset`` attribute, :math:`t` is given by the ``vector`` - attribute multiplied by the field value, and :math:`R` is defined as a rotation - about an axis in the direction of ``vector``, of angle of the field value. - - NOTE - - One possible use of ``NXtransformations`` is to define the motors and - transformations for a diffractometer (goniometer). Such use is mentioned - in the ``NXinstrument`` base class. Use one ``NXtransformations`` group - for each diffractometer and name the group appropriate to the device. - Collecting the motors of a sample table or xyz-stage in an NXtransformations - group is equally possible. - - - Following the section on the general dscription of axis in NXtransformations is a section which - documents the fields commonly used within NeXus for positioning purposes and their meaning. Whenever - there is a need for positioning a beam line component please use the existing names. Use as many fields - as needed in order to position the component. Feel free to add more axis if required. In the description - given below, only those atttributes which are defined through the name are spcified. Add the other attributes - of the full set: - - * vector - * offset - * transformation_type - * depends_on - - as needed. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/transformations@NX_class) -DEBUG - value: NXtransformations -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXtransformations'] -DEBUG - classes: -NXelectronanalyser.nxdl.xml:/TRANSFORMATIONS -NXtransformations.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/transformations/rot_y): -DEBUG - value: -115.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME): -DEBUG - - Units need to be appropriate for translation or rotation - - The name of this field is not forced. The user is free to use any name - that does not cause confusion. When using more than one ``AXISNAME`` field, - make sure that each field name is unique in the same group, as required - by HDF5. - - The values given should be the start points of exposures for the corresponding - frames. The end points should be given in ``AXISNAME_end``. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/transformations/rot_y@depends_on) -DEBUG - value: . -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@depends_on - [NX_CHAR] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/depends_on): -DEBUG - - Points to the path to a field defining the axis on which this - depends or the string ".". - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/transformations/rot_y@transformation_type) -DEBUG - value: rotation -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@transformation_type - [NX_CHAR] -DEBUG - <> -DEBUG - enumeration (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - -> translation -DEBUG - -> rotation -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - - The transformation_type may be ``translation``, in which case the - values are linear displacements along the axis, ``rotation``, - in which case the values are angular rotations around the axis. - - If this attribute is omitted, this is an axis for which there - is no motion to be specifies, such as the direction of gravity, - or the direction to the source, or a basis vector of a - coordinate frame. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/transformations/rot_y@units) -DEBUG - value: degrees -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@units [NX_TRANSFORMATION] -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/transformations/rot_y@vector) -DEBUG - value: [0 1 0] -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@vector - [NX_NUMBER] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/vector): -DEBUG - - Three values that define the axis for this transformation. - The axis should be normalized to unit length, making it - dimensionless. For ``rotation`` axes, the direction should be - chosen for a right-handed rotation with increasing angle. - For ``translation`` axes the direction should be chosen for - increasing displacement. For general axes, an appropriate direction - should be chosen. - -DEBUG - ===== FIELD (//entry/instrument/electronanalyser/transformations/trans_z): -DEBUG - value: 4.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME): -DEBUG - - Units need to be appropriate for translation or rotation - - The name of this field is not forced. The user is free to use any name - that does not cause confusion. When using more than one ``AXISNAME`` field, - make sure that each field name is unique in the same group, as required - by HDF5. - - The values given should be the start points of exposures for the corresponding - frames. The end points should be given in ``AXISNAME_end``. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/transformations/trans_z@depends_on) -DEBUG - value: rot_y -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@depends_on - [NX_CHAR] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/depends_on): -DEBUG - - Points to the path to a field defining the axis on which this - depends or the string ".". - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/transformations/trans_z@transformation_type) -DEBUG - value: translation -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@transformation_type - [NX_CHAR] -DEBUG - <> -DEBUG - enumeration (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - -> translation -DEBUG - -> rotation -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - - The transformation_type may be ``translation``, in which case the - values are linear displacements along the axis, ``rotation``, - in which case the values are angular rotations around the axis. - - If this attribute is omitted, this is an axis for which there - is no motion to be specifies, such as the direction of gravity, - or the direction to the source, or a basis vector of a - coordinate frame. - -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/transformations/trans_z@units) -DEBUG - value: mm -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@units [NX_TRANSFORMATION] -DEBUG - ===== ATTRS (//entry/instrument/electronanalyser/transformations/trans_z@vector) -DEBUG - value: [0 0 1] -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXelectronanalyser', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@vector - [NX_NUMBER] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/vector): -DEBUG - - Three values that define the axis for this transformation. - The axis should be normalized to unit length, making it - dimensionless. For ``rotation`` axes, the direction should be - chosen for a right-handed rotation with increasing angle. - For ``translation`` axes the direction should be chosen for - increasing displacement. For general axes, an appropriate direction - should be chosen. - -DEBUG - ===== FIELD (//entry/instrument/energy_resolution): -DEBUG - value: 140.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NX_FLOAT'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/energy_resolution -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/energy_resolution): -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/energy_resolution@units) -DEBUG - value: meV -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NX_FLOAT'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/energy_resolution -DEBUG - NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/energy_resolution@units [NX_ENERGY] -DEBUG - ===== GROUP (//entry/instrument/manipulator [NXmpes::/NXentry/NXinstrument/NXmanipulator]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/MANIPULATOR -NXmanipulator.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/MANIPULATOR): -DEBUG - - Manipulator for positioning of the sample. - -DEBUG - documentation (NXmanipulator.nxdl.xml:): -DEBUG - - Extension of NXpositioner to include fields to describe the use of manipulators - in photoemission experiments. - -DEBUG - ===== ATTRS (//entry/instrument/manipulator@NX_class) -DEBUG - value: NXmanipulator -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/MANIPULATOR -NXmanipulator.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/manipulator/depends_on): -DEBUG - value: b'/entry/instrument/manipulator/transformations/trans_z' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NX_CHAR'] -DEBUG - classes: -NXmanipulator.nxdl.xml:/depends_on -DEBUG - <> -DEBUG - documentation (NXmanipulator.nxdl.xml:/depends_on): -DEBUG - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - -DEBUG - ===== FIELD (//entry/instrument/manipulator/sample_bias): -DEBUG - value: 17.799719004221362 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NX_FLOAT'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/MANIPULATOR/sample_bias -NXmanipulator.nxdl.xml:/sample_bias -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/MANIPULATOR/sample_bias): -DEBUG - -DEBUG - documentation (NXmanipulator.nxdl.xml:/sample_bias): -DEBUG - - Possible bias of the sample with trespect to analyser ground. This field may - also be found in NXsample if present. - -DEBUG - ===== ATTRS (//entry/instrument/manipulator/sample_bias@units) -DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NX_FLOAT'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/MANIPULATOR/sample_bias -NXmanipulator.nxdl.xml:/sample_bias -DEBUG - NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/MANIPULATOR/sample_bias@units [NX_CURRENT] -DEBUG - NXmanipulator.nxdl.xml:/sample_bias@units [NX_CURRENT] -DEBUG - ===== FIELD (//entry/instrument/manipulator/sample_temperature): -DEBUG - value: 23.050763803680983 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NX_FLOAT'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/MANIPULATOR/sample_temperature -NXmanipulator.nxdl.xml:/sample_temperature -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/MANIPULATOR/sample_temperature): -DEBUG - -DEBUG - documentation (NXmanipulator.nxdl.xml:/sample_temperature): -DEBUG - - Temperature at the closest point to the sample. This field may also be found in - NXsample if present. - -DEBUG - ===== ATTRS (//entry/instrument/manipulator/sample_temperature@units) -DEBUG - value: K -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NX_FLOAT'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/MANIPULATOR/sample_temperature -NXmanipulator.nxdl.xml:/sample_temperature -DEBUG - NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/MANIPULATOR/sample_temperature@units [NX_TEMPERATURE] -DEBUG - NXmanipulator.nxdl.xml:/sample_temperature@units [NX_TEMPERATURE] -DEBUG - ===== GROUP (//entry/instrument/manipulator/transformations [NXmpes::/NXentry/NXinstrument/NXmanipulator/NXtransformations]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NXtransformations'] -DEBUG - classes: -NXmanipulator.nxdl.xml:/TRANSFORMATIONS -NXtransformations.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmanipulator.nxdl.xml:/TRANSFORMATIONS): -DEBUG - - 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. - -DEBUG - documentation (NXtransformations.nxdl.xml:): -DEBUG - - Collection of axis-based translations and rotations to describe a geometry. - May also contain axes that do not move and therefore do not have a transformation - type specified, but are useful in understanding coordinate frames within which - transformations are done, or in documenting important directions, such as the - direction of gravity. - - A nested sequence of transformations lists the translation and rotation steps - needed to describe the position and orientation of any movable or fixed device. - - There will be one or more transformations (axes) defined by one or more fields - for each transformation. Transformations can also be described by NXlog groups when - the values change with time. The all-caps name ``AXISNAME`` designates the - particular axis generating a transformation (e.g. a rotation axis or a translation - axis or a general axis). The attribute ``units="NX_TRANSFORMATION"`` designates the - units will be appropriate to the ``transformation_type`` attribute: - - * ``NX_LENGTH`` for ``translation`` - * ``NX_ANGLE`` for ``rotation`` - * ``NX_UNITLESS`` for axes for which no transformation type is specified - - This class will usually contain all axes of a sample stage or goniometer or - a detector. The NeXus default McSTAS coordinate frame is assumed, but additional - useful coordinate axes may be defined by using axes for which no transformation - type has been specified. - - The entry point (``depends_on``) will be outside of this class and point to a - field in here. Following the chain may also require following ``depends_on`` - links to transformations outside, for example to a common base table. If - a relative path is given, it is relative to the group enclosing the ``depends_on`` - specification. - - For a chain of three transformations, where :math:`T_1` depends on :math:`T_2` - and that in turn depends on :math:`T_3`, the final transformation :math:`T_f` is - - .. math:: T_f = T_3 T_2 T_1 - - In explicit terms, the transformations are a subset of affine transformations - expressed as 4x4 matrices that act on homogeneous coordinates, :math:`w=(x,y,z,1)^T`. - - For rotation and translation, - - .. math:: T_r &= \begin{pmatrix} R & o \\ 0_3 & 1 \end{pmatrix} \\ T_t &= \begin{pmatrix} I_3 & t + o \\ 0_3 & 1 \end{pmatrix} - - where :math:`R` is the usual 3x3 rotation matrix, :math:`o` is an offset vector, - :math:`0_3` is a row of 3 zeros, :math:`I_3` is the 3x3 identity matrix and - :math:`t` is the translation vector. - - :math:`o` is given by the ``offset`` attribute, :math:`t` is given by the ``vector`` - attribute multiplied by the field value, and :math:`R` is defined as a rotation - about an axis in the direction of ``vector``, of angle of the field value. - - NOTE - - One possible use of ``NXtransformations`` is to define the motors and - transformations for a diffractometer (goniometer). Such use is mentioned - in the ``NXinstrument`` base class. Use one ``NXtransformations`` group - for each diffractometer and name the group appropriate to the device. - Collecting the motors of a sample table or xyz-stage in an NXtransformations - group is equally possible. - - - Following the section on the general dscription of axis in NXtransformations is a section which - documents the fields commonly used within NeXus for positioning purposes and their meaning. Whenever - there is a need for positioning a beam line component please use the existing names. Use as many fields - as needed in order to position the component. Feel free to add more axis if required. In the description - given below, only those atttributes which are defined through the name are spcified. Add the other attributes - of the full set: - - * vector - * offset - * transformation_type - * depends_on - - as needed. - -DEBUG - ===== ATTRS (//entry/instrument/manipulator/transformations@NX_class) -DEBUG - value: NXtransformations -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NXtransformations'] -DEBUG - classes: -NXmanipulator.nxdl.xml:/TRANSFORMATIONS -NXtransformations.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/manipulator/transformations/rot_x): -DEBUG - value: -90.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME): -DEBUG - - Units need to be appropriate for translation or rotation - - The name of this field is not forced. The user is free to use any name - that does not cause confusion. When using more than one ``AXISNAME`` field, - make sure that each field name is unique in the same group, as required - by HDF5. - - The values given should be the start points of exposures for the corresponding - frames. The end points should be given in ``AXISNAME_end``. - -DEBUG - ===== ATTRS (//entry/instrument/manipulator/transformations/rot_x@depends_on) -DEBUG - value: . -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@depends_on - [NX_CHAR] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/depends_on): -DEBUG - - Points to the path to a field defining the axis on which this - depends or the string ".". - -DEBUG - ===== ATTRS (//entry/instrument/manipulator/transformations/rot_x@transformation_type) -DEBUG - value: rotation -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@transformation_type - [NX_CHAR] -DEBUG - <> -DEBUG - enumeration (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - -> translation -DEBUG - -> rotation -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - - The transformation_type may be ``translation``, in which case the - values are linear displacements along the axis, ``rotation``, - in which case the values are angular rotations around the axis. - - If this attribute is omitted, this is an axis for which there - is no motion to be specifies, such as the direction of gravity, - or the direction to the source, or a basis vector of a - coordinate frame. - -DEBUG - ===== ATTRS (//entry/instrument/manipulator/transformations/rot_x@units) -DEBUG - value: degrees -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@units [NX_TRANSFORMATION] -DEBUG - ===== ATTRS (//entry/instrument/manipulator/transformations/rot_x@vector) -DEBUG - value: [1 0 0] -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@vector - [NX_NUMBER] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/vector): -DEBUG - - Three values that define the axis for this transformation. - The axis should be normalized to unit length, making it - dimensionless. For ``rotation`` axes, the direction should be - chosen for a right-handed rotation with increasing angle. - For ``translation`` axes the direction should be chosen for - increasing displacement. For general axes, an appropriate direction - should be chosen. - -DEBUG - ===== FIELD (//entry/instrument/manipulator/transformations/rot_z): -DEBUG - value: -25.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME): -DEBUG - - Units need to be appropriate for translation or rotation - - The name of this field is not forced. The user is free to use any name - that does not cause confusion. When using more than one ``AXISNAME`` field, - make sure that each field name is unique in the same group, as required - by HDF5. - - The values given should be the start points of exposures for the corresponding - frames. The end points should be given in ``AXISNAME_end``. - -DEBUG - ===== ATTRS (//entry/instrument/manipulator/transformations/rot_z@depends_on) -DEBUG - value: rot_x -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@depends_on - [NX_CHAR] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/depends_on): -DEBUG - - Points to the path to a field defining the axis on which this - depends or the string ".". - -DEBUG - ===== ATTRS (//entry/instrument/manipulator/transformations/rot_z@transformation_type) -DEBUG - value: rotation -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@transformation_type - [NX_CHAR] -DEBUG - <> -DEBUG - enumeration (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - -> translation -DEBUG - -> rotation -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - - The transformation_type may be ``translation``, in which case the - values are linear displacements along the axis, ``rotation``, - in which case the values are angular rotations around the axis. - - If this attribute is omitted, this is an axis for which there - is no motion to be specifies, such as the direction of gravity, - or the direction to the source, or a basis vector of a - coordinate frame. - -DEBUG - ===== ATTRS (//entry/instrument/manipulator/transformations/rot_z@units) -DEBUG - value: degrees -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@units [NX_TRANSFORMATION] -DEBUG - ===== ATTRS (//entry/instrument/manipulator/transformations/rot_z@vector) -DEBUG - value: [0 0 1] -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@vector - [NX_NUMBER] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/vector): -DEBUG - - Three values that define the axis for this transformation. - The axis should be normalized to unit length, making it - dimensionless. For ``rotation`` axes, the direction should be - chosen for a right-handed rotation with increasing angle. - For ``translation`` axes the direction should be chosen for - increasing displacement. For general axes, an appropriate direction - should be chosen. - -DEBUG - ===== FIELD (//entry/instrument/manipulator/transformations/trans_z): -DEBUG - value: -0.32 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME): -DEBUG - - Units need to be appropriate for translation or rotation - - The name of this field is not forced. The user is free to use any name - that does not cause confusion. When using more than one ``AXISNAME`` field, - make sure that each field name is unique in the same group, as required - by HDF5. - - The values given should be the start points of exposures for the corresponding - frames. The end points should be given in ``AXISNAME_end``. - -DEBUG - ===== ATTRS (//entry/instrument/manipulator/transformations/trans_z@depends_on) -DEBUG - value: rot_z -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@depends_on - [NX_CHAR] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/depends_on): -DEBUG - - Points to the path to a field defining the axis on which this - depends or the string ".". - -DEBUG - ===== ATTRS (//entry/instrument/manipulator/transformations/trans_z@transformation_type) -DEBUG - value: translation -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@transformation_type - [NX_CHAR] -DEBUG - <> -DEBUG - enumeration (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - -> translation -DEBUG - -> rotation -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - - The transformation_type may be ``translation``, in which case the - values are linear displacements along the axis, ``rotation``, - in which case the values are angular rotations around the axis. - - If this attribute is omitted, this is an axis for which there - is no motion to be specifies, such as the direction of gravity, - or the direction to the source, or a basis vector of a - coordinate frame. - -DEBUG - ===== ATTRS (//entry/instrument/manipulator/transformations/trans_z@units) -DEBUG - value: m -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@units [NX_TRANSFORMATION] -DEBUG - ===== ATTRS (//entry/instrument/manipulator/transformations/trans_z@vector) -DEBUG - value: [0 0 1] -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXmanipulator', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@vector - [NX_NUMBER] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/vector): -DEBUG - - Three values that define the axis for this transformation. - The axis should be normalized to unit length, making it - dimensionless. For ``rotation`` axes, the direction should be - chosen for a right-handed rotation with increasing angle. - For ``translation`` axes the direction should be chosen for - increasing displacement. For general axes, an appropriate direction - should be chosen. - -DEBUG - ===== FIELD (//entry/instrument/momentum_resolution): -DEBUG - value: 0.08 -DEBUG - classpath: ['NXentry', 'NXinstrument'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/momentum_resolution@units) -DEBUG - value: 1/angstrom -DEBUG - classpath: ['NXentry', 'NXinstrument'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/name): -DEBUG - value: b'Time-of-flight momentum microscope equipped delay line detector, at the endstation of the high rep-rate HHG source at FHI' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NX_CHAR'] -DEBUG - classes: -NXinstrument.nxdl.xml:/name -DEBUG - <> -DEBUG - documentation (NXinstrument.nxdl.xml:/name): -DEBUG - Name of instrument -DEBUG - ===== ATTRS (//entry/instrument/name@short_name) -DEBUG - value: TR-ARPES @ FHI -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NX_CHAR'] -DEBUG - classes: -NXinstrument.nxdl.xml:/name -DEBUG - NXinstrument.nxdl.xml:/name@short_name - [NX_CHAR] -DEBUG - <> -DEBUG - documentation (NXinstrument.nxdl.xml:/name/short_name): -DEBUG - short name for instrument, perhaps the acronym -DEBUG - ===== GROUP (//entry/instrument/source [NXmpes::/NXentry/NXinstrument/NXsource]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE -NXinstrument.nxdl.xml:/SOURCE -NXsource.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE): -DEBUG - - 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. - -DEBUG - documentation (NXinstrument.nxdl.xml:/SOURCE): -DEBUG - -DEBUG - documentation (NXsource.nxdl.xml:): -DEBUG - The neutron or x-ray storage ring/facility. -DEBUG - ===== ATTRS (//entry/instrument/source@NX_class) -DEBUG - value: NXsource -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE -NXinstrument.nxdl.xml:/SOURCE -NXsource.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/source/frequency): -DEBUG - value: 500.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_FLOAT'] -DEBUG - classes: -NXsource.nxdl.xml:/frequency -DEBUG - <> -DEBUG - documentation (NXsource.nxdl.xml:/frequency): -DEBUG - Frequency of pulsed source -DEBUG - ===== ATTRS (//entry/instrument/source/frequency@units) -DEBUG - value: kHz -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_FLOAT'] -DEBUG - classes: -NXsource.nxdl.xml:/frequency -DEBUG - NXsource.nxdl.xml:/frequency@units [NX_FREQUENCY] -DEBUG - ===== FIELD (//entry/instrument/source/mode): -DEBUG - value: b'Single Bunch' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_CHAR'] -DEBUG - classes: -NXsource.nxdl.xml:/mode -DEBUG - <> -DEBUG - enumeration (NXsource.nxdl.xml:/mode): -DEBUG - -> Single Bunch -DEBUG - -> Multi Bunch -DEBUG - documentation (NXsource.nxdl.xml:/mode): -DEBUG - source operating mode -DEBUG - ===== FIELD (//entry/instrument/source/name): -DEBUG - value: b'HHG @ TR-ARPES @ FHI' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/name -NXsource.nxdl.xml:/name -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/name): -DEBUG - -DEBUG - documentation (NXsource.nxdl.xml:/name): -DEBUG - Name of source -DEBUG - ===== FIELD (//entry/instrument/source/photon_energy): -DEBUG - value: 21.7 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/source/photon_energy@units) -DEBUG - value: eV -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/source/probe): -DEBUG - value: b'ultraviolet' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/probe -NXsource.nxdl.xml:/probe -DEBUG - <> -DEBUG - enumeration (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/probe): -DEBUG - -> x-ray -DEBUG - -> ultraviolet -DEBUG - -> visible light -DEBUG - enumeration (NXsource.nxdl.xml:/probe): -DEBUG - -> neutron -DEBUG - -> x-ray -DEBUG - -> muon -DEBUG - -> electron -DEBUG - -> ultraviolet -DEBUG - -> visible light -DEBUG - -> positron -DEBUG - -> proton -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/probe): -DEBUG - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - -DEBUG - documentation (NXsource.nxdl.xml:/probe): -DEBUG - type of radiation probe (pick one from the enumerated list and spell exactly) -DEBUG - ===== FIELD (//entry/instrument/source/type): -DEBUG - value: b'HHG laser' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/type -NXsource.nxdl.xml:/type -DEBUG - <> -DEBUG - enumeration (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/type): -DEBUG - -> Synchrotron X-ray Source -DEBUG - -> Rotating Anode X-ray -DEBUG - -> Fixed Tube X-ray -DEBUG - -> UV Laser -DEBUG - -> Free-Electron Laser -DEBUG - -> Optical Laser -DEBUG - -> UV Plasma Source -DEBUG - -> Metal Jet X-ray -DEBUG - -> HHG laser -DEBUG - enumeration (NXsource.nxdl.xml:/type): -DEBUG - -> Spallation Neutron Source -DEBUG - -> Pulsed Reactor Neutron Source -DEBUG - -> Reactor Neutron Source -DEBUG - -> Synchrotron X-ray Source -DEBUG - -> Pulsed Muon Source -DEBUG - -> Rotating Anode X-ray -DEBUG - -> Fixed Tube X-ray -DEBUG - -> UV Laser -DEBUG - -> Free-Electron Laser -DEBUG - -> Optical Laser -DEBUG - -> Ion Source -DEBUG - -> UV Plasma Source -DEBUG - -> Metal Jet X-ray -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/type): -DEBUG - -DEBUG - documentation (NXsource.nxdl.xml:/type): -DEBUG - type of radiation source (pick one from the enumerated list and spell exactly) -DEBUG - ===== GROUP (//entry/instrument/source_pump [NXmpes::/NXentry/NXinstrument/NXsource]): -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE -NXinstrument.nxdl.xml:/SOURCE -NXsource.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE): -DEBUG - - 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. - -DEBUG - documentation (NXinstrument.nxdl.xml:/SOURCE): -DEBUG - -DEBUG - documentation (NXsource.nxdl.xml:): -DEBUG - The neutron or x-ray storage ring/facility. -DEBUG - ===== ATTRS (//entry/instrument/source_pump@NX_class) -DEBUG - value: NXsource -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE -NXinstrument.nxdl.xml:/SOURCE -NXsource.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/source_pump/frequency): -DEBUG - value: 500.0 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_FLOAT'] -DEBUG - classes: -NXsource.nxdl.xml:/frequency -DEBUG - <> -DEBUG - documentation (NXsource.nxdl.xml:/frequency): -DEBUG - Frequency of pulsed source -DEBUG - ===== ATTRS (//entry/instrument/source_pump/frequency@units) -DEBUG - value: kHz -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_FLOAT'] -DEBUG - classes: -NXsource.nxdl.xml:/frequency -DEBUG - NXsource.nxdl.xml:/frequency@units [NX_FREQUENCY] -DEBUG - ===== FIELD (//entry/instrument/source_pump/mode): -DEBUG - value: b'Single Bunch' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_CHAR'] -DEBUG - classes: -NXsource.nxdl.xml:/mode -DEBUG - <> -DEBUG - enumeration (NXsource.nxdl.xml:/mode): -DEBUG - -> Single Bunch -DEBUG - -> Multi Bunch -DEBUG - documentation (NXsource.nxdl.xml:/mode): -DEBUG - source operating mode -DEBUG - ===== FIELD (//entry/instrument/source_pump/name): -DEBUG - value: b'OPCPA @ TR-ARPES @ FHI' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/name -NXsource.nxdl.xml:/name -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/name): -DEBUG - -DEBUG - documentation (NXsource.nxdl.xml:/name): -DEBUG - Name of source -DEBUG - ===== FIELD (//entry/instrument/source_pump/photon_energy): -DEBUG - value: 1.2 -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/source_pump/photon_energy@units) -DEBUG - value: eV -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/instrument/source_pump/probe): -DEBUG - value: b'visible light' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/probe -NXsource.nxdl.xml:/probe -DEBUG - <> -DEBUG - enumeration (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/probe): -DEBUG - -> x-ray -DEBUG - -> ultraviolet -DEBUG - -> visible light -DEBUG - enumeration (NXsource.nxdl.xml:/probe): -DEBUG - -> neutron -DEBUG - -> x-ray -DEBUG - -> muon -DEBUG - -> electron -DEBUG - -> ultraviolet -DEBUG - -> visible light -DEBUG - -> positron -DEBUG - -> proton -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/probe): -DEBUG - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - -DEBUG - documentation (NXsource.nxdl.xml:/probe): -DEBUG - type of radiation probe (pick one from the enumerated list and spell exactly) -DEBUG - ===== FIELD (//entry/instrument/source_pump/type): -DEBUG - value: b'Optical Laser' -DEBUG - classpath: ['NXentry', 'NXinstrument', 'NXsource', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/type -NXsource.nxdl.xml:/type -DEBUG - <> -DEBUG - enumeration (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/type): -DEBUG - -> Synchrotron X-ray Source -DEBUG - -> Rotating Anode X-ray -DEBUG - -> Fixed Tube X-ray -DEBUG - -> UV Laser -DEBUG - -> Free-Electron Laser -DEBUG - -> Optical Laser -DEBUG - -> UV Plasma Source -DEBUG - -> Metal Jet X-ray -DEBUG - -> HHG laser -DEBUG - enumeration (NXsource.nxdl.xml:/type): -DEBUG - -> Spallation Neutron Source -DEBUG - -> Pulsed Reactor Neutron Source -DEBUG - -> Reactor Neutron Source -DEBUG - -> Synchrotron X-ray Source -DEBUG - -> Pulsed Muon Source -DEBUG - -> Rotating Anode X-ray -DEBUG - -> Fixed Tube X-ray -DEBUG - -> UV Laser -DEBUG - -> Free-Electron Laser -DEBUG - -> Optical Laser -DEBUG - -> Ion Source -DEBUG - -> UV Plasma Source -DEBUG - -> Metal Jet X-ray -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/INSTRUMENT/SOURCE/type): -DEBUG - -DEBUG - documentation (NXsource.nxdl.xml:/type): -DEBUG - type of radiation source (pick one from the enumerated list and spell exactly) -DEBUG - ===== FIELD (//entry/instrument/temporal_resolution): -DEBUG - value: 35.0 -DEBUG - classpath: ['NXentry', 'NXinstrument'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/instrument/temporal_resolution@units) -DEBUG - value: fs -DEBUG - classpath: ['NXentry', 'NXinstrument'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== GROUP (//entry/process [NXmpes::/NXentry/NXprocess]): -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/PROCESS -NXentry.nxdl.xml:/PROCESS -NXprocess.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/PROCESS): -DEBUG - - 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 - -DEBUG - documentation (NXentry.nxdl.xml:/PROCESS): -DEBUG - -DEBUG - documentation (NXprocess.nxdl.xml:): -DEBUG - Document an event of data processing, reconstruction, or analysis for this data. -DEBUG - ===== ATTRS (//entry/process@NX_class) -DEBUG - value: NXprocess -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/PROCESS -NXentry.nxdl.xml:/PROCESS -NXprocess.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== GROUP (//entry/process/distortion [NXmpes::/NXentry/NXprocess/distortion]): -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/process/distortion/applied): -DEBUG - value: True -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/process/distortion/cdeform_field): -DEBUG - value: [0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. ... -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/process/distortion/original_centre): -DEBUG - value: [203. 215.] -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/process/distortion/original_points): -DEBUG - value: [166. 283.] -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/process/distortion/rdeform_field): -DEBUG - value: [0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. ... -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/process/distortion/symmetry): -DEBUG - value: 6 -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== GROUP (//entry/process/energy_calibration [NXmpes::/NXentry/NXprocess/NXcalibration]): -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXcalibration'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/PROCESS/energy_calibration -NXcalibration.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/PROCESS/energy_calibration): -DEBUG - -DEBUG - documentation (NXcalibration.nxdl.xml:): -DEBUG - - Subclass of NXprocess to describe post-processing calibrations. - -DEBUG - ===== ATTRS (//entry/process/energy_calibration@NX_class) -DEBUG - value: NXcalibration -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXcalibration'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/PROCESS/energy_calibration -NXcalibration.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/process/energy_calibration/applied): -DEBUG - value: True -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXcalibration', 'NX_BOOLEAN'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/PROCESS/energy_calibration/applied -NXcalibration.nxdl.xml:/applied -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/PROCESS/energy_calibration/applied): -DEBUG - - Has an energy calibration been applied? - -DEBUG - documentation (NXcalibration.nxdl.xml:/applied): -DEBUG - - Has the calibration been applied? - -DEBUG - ===== FIELD (//entry/process/energy_calibration/calibrated_axis): -DEBUG - value: [ 5.22069940e+01 5.10746894e+01 4.99673811e+01 4.88843387e+01 ... -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXcalibration', 'NX_FLOAT'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/PROCESS/energy_calibration/calibrated_axis -NXcalibration.nxdl.xml:/calibrated_axis -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/PROCESS/energy_calibration/calibrated_axis): -DEBUG - - This is the calibrated energy axis to be used for data plotting. - -DEBUG - documentation (NXcalibration.nxdl.xml:/calibrated_axis): -DEBUG - - A vector representing the axis after calibration, matching the data length - -DEBUG - ===== FIELD (//entry/process/energy_calibration/fit_function): -DEBUG - value: b'(a0/(x0-a1))**2 + a2' -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXcalibration', 'NX_CHAR'] -DEBUG - classes: -NXcalibration.nxdl.xml:/fit_function -DEBUG - <> -DEBUG - documentation (NXcalibration.nxdl.xml:/fit_function): -DEBUG - - 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. - -DEBUG - ===== FIELD (//entry/process/energy_calibration/original_axis): -DEBUG - value: [ 60027.77777778 60083.33333333 60138.88888889 60194.44444444 ... -DEBUG - classpath: ['NXentry', 'NXprocess', 'NXcalibration', 'NX_FLOAT'] -DEBUG - classes: -NXcalibration.nxdl.xml:/original_axis -DEBUG - <> -DEBUG - documentation (NXcalibration.nxdl.xml:/original_axis): -DEBUG - - Vector containing the data coordinates in the original uncalibrated axis - -DEBUG - ===== GROUP (//entry/process/kx_calibration [NXmpes::/NXentry/NXprocess/kx_calibration]): -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/process/kx_calibration/applied): -DEBUG - value: True -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/process/kx_calibration/calibrated_axis): -DEBUG - value: [-2.68021375 -2.66974416 -2.65927458 -2.64880499 -2.63833541 -2.62786582 ... -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/process/kx_calibration/offset): -DEBUG - value: 256.0 -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/process/kx_calibration/scaling): -DEBUG - value: 0.01046958495673419 -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== GROUP (//entry/process/ky_calibration [NXmpes::/NXentry/NXprocess/ky_calibration]): -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/process/ky_calibration/applied): -DEBUG - value: True -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/process/ky_calibration/calibrated_axis): -DEBUG - value: [-2.68021375 -2.66974416 -2.65927458 -2.64880499 -2.63833541 -2.62786582 ... -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/process/ky_calibration/offset): -DEBUG - value: 256.0 -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/process/ky_calibration/scaling): -DEBUG - value: 0.01046958495673419 -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== GROUP (//entry/process/registration [NXmpes::/NXentry/NXprocess/registration]): -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/process/registration/applied): -DEBUG - value: True -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/process/registration/depends_on): -DEBUG - value: b'/entry/process/registration/tranformations/rot_z' -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== GROUP (//entry/process/registration/tranformations [NXmpes::/NXentry/NXprocess/registration/tranformations]): -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/process/registration/tranformations/rot_z): -DEBUG - value: -1.0 -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/process/registration/tranformations/rot_z@depends_on) -DEBUG - value: trans_y -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/process/registration/tranformations/rot_z@offset) -DEBUG - value: [256. 256. 0.] -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/process/registration/tranformations/rot_z@transformation_type) -DEBUG - value: rotation -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/process/registration/tranformations/rot_z@units) -DEBUG - value: degrees -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/process/registration/tranformations/rot_z@vector) -DEBUG - value: [0. 0. 1.] -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/process/registration/tranformations/trans_x): -DEBUG - value: 43.0 -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/process/registration/tranformations/trans_x@depends_on) -DEBUG - value: . -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/process/registration/tranformations/trans_x@transformation_type) -DEBUG - value: translation -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/process/registration/tranformations/trans_x@units) -DEBUG - value: pixels -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/process/registration/tranformations/trans_x@vector) -DEBUG - value: [1. 0. 0.] -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/process/registration/tranformations/trans_y): -DEBUG - value: 55.0 -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/process/registration/tranformations/trans_y@depends_on) -DEBUG - value: trans_x -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/process/registration/tranformations/trans_y@transformation_type) -DEBUG - value: translation -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/process/registration/tranformations/trans_y@units) -DEBUG - value: pixels -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/process/registration/tranformations/trans_y@vector) -DEBUG - value: [0. 1. 0.] -DEBUG - classpath: ['NXentry', 'NXprocess'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== GROUP (//entry/sample [NXmpes::/NXentry/NXsample]): -DEBUG - classpath: ['NXentry', 'NXsample'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/SAMPLE -NXentry.nxdl.xml:/SAMPLE -NXsample.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/SAMPLE): -DEBUG - -DEBUG - documentation (NXentry.nxdl.xml:/SAMPLE): -DEBUG - -DEBUG - documentation (NXsample.nxdl.xml:): -DEBUG - - Any information on the sample. - - This could include scanned variables that - are associated with one of the data dimensions, e.g. the magnetic field, or - logged data, e.g. monitored temperature vs elapsed time. - -DEBUG - ===== ATTRS (//entry/sample@NX_class) -DEBUG - value: NXsample -DEBUG - classpath: ['NXentry', 'NXsample'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/SAMPLE -NXentry.nxdl.xml:/SAMPLE -NXsample.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/sample/bias): -DEBUG - value: 17.799719004221362 -DEBUG - classpath: ['NXentry', 'NXsample'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== ATTRS (//entry/sample/bias@units) -DEBUG - value: V -DEBUG - classpath: ['NXentry', 'NXsample'] -DEBUG - NOT IN SCHEMA -DEBUG - -DEBUG - ===== FIELD (//entry/sample/chemical_formula): -DEBUG - value: b'MoTe2' -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/SAMPLE/chemical_formula -NXsample.nxdl.xml:/chemical_formula -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/SAMPLE/chemical_formula): -DEBUG - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - -DEBUG - documentation (NXsample.nxdl.xml:/chemical_formula): -DEBUG - - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard: - - * Only recognized element symbols may be used. - * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. - * A space or parenthesis must separate each cluster of (element symbol + count). - * Where a group of elements is enclosed in parentheses, the multiplier for the - group must follow the closing parentheses. That is, all element and group - multipliers are assumed to be printed as subscripted numbers. - * Unless the elements are ordered in a manner that corresponds to their chemical - structure, the order of the elements within any group or moiety depends on - whether or not carbon is present. - * If carbon is present, the order should be: - - - C, then H, then the other elements in alphabetical order of their symbol. - - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. - - * This is the *Hill* system used by Chemical Abstracts. - -DEBUG - ===== FIELD (//entry/sample/depends_on): -DEBUG - value: b'/entry/sample/transformations/corrected_phi' -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_CHAR'] -DEBUG - classes: -NXsample.nxdl.xml:/depends_on -DEBUG - <> -DEBUG - documentation (NXsample.nxdl.xml:/depends_on): -DEBUG - - 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. - -DEBUG - ===== FIELD (//entry/sample/description): -DEBUG - value: b'MoTe2' -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_CHAR'] -DEBUG - classes: -NXsample.nxdl.xml:/description -DEBUG - <> -DEBUG - documentation (NXsample.nxdl.xml:/description): -DEBUG - - Description of the sample - -DEBUG - ===== FIELD (//entry/sample/gas_pressure): -DEBUG - value: 4.5599999999999996e-11 -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_FLOAT'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/SAMPLE/gas_pressure -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/SAMPLE/gas_pressure): -DEBUG - -DEBUG - ===== ATTRS (//entry/sample/gas_pressure@units) -DEBUG - value: mbar -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_FLOAT'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/SAMPLE/gas_pressure -DEBUG - NXmpes.nxdl.xml:/ENTRY/SAMPLE/gas_pressure@units [NX_PRESSURE] -DEBUG - ===== FIELD (//entry/sample/name): -DEBUG - value: b'MoTe2' -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/SAMPLE/name -NXsample.nxdl.xml:/name -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/SAMPLE/name): -DEBUG - -DEBUG - documentation (NXsample.nxdl.xml:/name): -DEBUG - Descriptive name of sample -DEBUG - ===== FIELD (//entry/sample/preparation_date): -DEBUG - value: b'2019-05-22T14:00:00+00:00' -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_DATE_TIME'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/SAMPLE/preparation_date -NXsample.nxdl.xml:/preparation_date -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/SAMPLE/preparation_date): -DEBUG - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - -DEBUG - documentation (NXsample.nxdl.xml:/preparation_date): -DEBUG - Date of preparation of the sample -DEBUG - ===== GROUP (//entry/sample/preparation_description [NXmpes::/NXentry/NXsample/NXnote]): -DEBUG - classpath: ['NXentry', 'NXsample', 'NXnote'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/SAMPLE/preparation_description -NXnote.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/SAMPLE/preparation_description): -DEBUG - - 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. - -DEBUG - documentation (NXnote.nxdl.xml:): -DEBUG - - Any additional freeform information not covered by the other base classes. - - This class can be used to store additional information in a - NeXus file e.g. pictures, movies, audio, additional text logs - -DEBUG - ===== ATTRS (//entry/sample/preparation_description@NX_class) -DEBUG - value: NXnote -DEBUG - classpath: ['NXentry', 'NXsample', 'NXnote'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/SAMPLE/preparation_description -NXnote.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/sample/preparation_description/description): -DEBUG - value: b'Here should be a description of the preparation procedure.' -DEBUG - classpath: ['NXentry', 'NXsample', 'NXnote', 'NX_CHAR'] -DEBUG - classes: -NXnote.nxdl.xml:/description -DEBUG - <> -DEBUG - documentation (NXnote.nxdl.xml:/description): -DEBUG - Title of an image or other details of the note -DEBUG - ===== GROUP (//entry/sample/sample_history [NXmpes::/NXentry/NXsample/NXnote]): -DEBUG - classpath: ['NXentry', 'NXsample', 'NXnote'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/SAMPLE/sample_history -NXnote.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/SAMPLE/sample_history): -DEBUG - - 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. - -DEBUG - documentation (NXnote.nxdl.xml:): -DEBUG - - Any additional freeform information not covered by the other base classes. - - This class can be used to store additional information in a - NeXus file e.g. pictures, movies, audio, additional text logs - -DEBUG - ===== ATTRS (//entry/sample/sample_history@NX_class) -DEBUG - value: NXnote -DEBUG - classpath: ['NXentry', 'NXsample', 'NXnote'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/SAMPLE/sample_history -NXnote.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/sample/sample_history/description): -DEBUG - value: b'Cleaved' -DEBUG - classpath: ['NXentry', 'NXsample', 'NXnote', 'NX_CHAR'] -DEBUG - classes: -NXnote.nxdl.xml:/description -DEBUG - <> -DEBUG - documentation (NXnote.nxdl.xml:/description): -DEBUG - Title of an image or other details of the note -DEBUG - ===== FIELD (//entry/sample/situation): -DEBUG - value: b'vacuum' -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/SAMPLE/situation -NXsample.nxdl.xml:/situation -DEBUG - <> -DEBUG - enumeration (NXmpes.nxdl.xml:/ENTRY/SAMPLE/situation): -DEBUG - -> vacuum -DEBUG - -> inert atmosphere -DEBUG - -> oxidising atmosphere -DEBUG - -> reducing atmosphere -DEBUG - enumeration (NXsample.nxdl.xml:/situation): -DEBUG - -> air -DEBUG - -> vacuum -DEBUG - -> inert atmosphere -DEBUG - -> oxidising atmosphere -DEBUG - -> reducing atmosphere -DEBUG - -> sealed can -DEBUG - -> other -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/SAMPLE/situation): -DEBUG - -DEBUG - documentation (NXsample.nxdl.xml:/situation): -DEBUG - - The atmosphere will be one of the components, which is where - its details will be stored; the relevant components will be - indicated by the entry in the sample_component member. - -DEBUG - ===== FIELD (//entry/sample/temperature): -DEBUG - value: 23.050763803680983 -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_FLOAT'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/SAMPLE/temperature -NXsample.nxdl.xml:/temperature -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/SAMPLE/temperature): -DEBUG - - 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. - -DEBUG - documentation (NXsample.nxdl.xml:/temperature): -DEBUG - Sample temperature. This could be a scanned variable -DEBUG - ===== ATTRS (//entry/sample/temperature@units) -DEBUG - value: K -DEBUG - classpath: ['NXentry', 'NXsample', 'NX_FLOAT'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/SAMPLE/temperature -NXsample.nxdl.xml:/temperature -DEBUG - NXmpes.nxdl.xml:/ENTRY/SAMPLE/temperature@units [NX_TEMPERATURE] -DEBUG - NXsample.nxdl.xml:/temperature@units [NX_TEMPERATURE] -DEBUG - ===== GROUP (//entry/sample/transformations [NXmpes::/NXentry/NXsample/NXtransformations]): -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations'] -DEBUG - classes: -NXsample.nxdl.xml:/TRANSFORMATIONS -NXtransformations.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXsample.nxdl.xml:/TRANSFORMATIONS): -DEBUG - - 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. - -DEBUG - documentation (NXtransformations.nxdl.xml:): -DEBUG - - Collection of axis-based translations and rotations to describe a geometry. - May also contain axes that do not move and therefore do not have a transformation - type specified, but are useful in understanding coordinate frames within which - transformations are done, or in documenting important directions, such as the - direction of gravity. - - A nested sequence of transformations lists the translation and rotation steps - needed to describe the position and orientation of any movable or fixed device. - - There will be one or more transformations (axes) defined by one or more fields - for each transformation. Transformations can also be described by NXlog groups when - the values change with time. The all-caps name ``AXISNAME`` designates the - particular axis generating a transformation (e.g. a rotation axis or a translation - axis or a general axis). The attribute ``units="NX_TRANSFORMATION"`` designates the - units will be appropriate to the ``transformation_type`` attribute: - - * ``NX_LENGTH`` for ``translation`` - * ``NX_ANGLE`` for ``rotation`` - * ``NX_UNITLESS`` for axes for which no transformation type is specified - - This class will usually contain all axes of a sample stage or goniometer or - a detector. The NeXus default McSTAS coordinate frame is assumed, but additional - useful coordinate axes may be defined by using axes for which no transformation - type has been specified. - - The entry point (``depends_on``) will be outside of this class and point to a - field in here. Following the chain may also require following ``depends_on`` - links to transformations outside, for example to a common base table. If - a relative path is given, it is relative to the group enclosing the ``depends_on`` - specification. - - For a chain of three transformations, where :math:`T_1` depends on :math:`T_2` - and that in turn depends on :math:`T_3`, the final transformation :math:`T_f` is - - .. math:: T_f = T_3 T_2 T_1 - - In explicit terms, the transformations are a subset of affine transformations - expressed as 4x4 matrices that act on homogeneous coordinates, :math:`w=(x,y,z,1)^T`. - - For rotation and translation, - - .. math:: T_r &= \begin{pmatrix} R & o \\ 0_3 & 1 \end{pmatrix} \\ T_t &= \begin{pmatrix} I_3 & t + o \\ 0_3 & 1 \end{pmatrix} - - where :math:`R` is the usual 3x3 rotation matrix, :math:`o` is an offset vector, - :math:`0_3` is a row of 3 zeros, :math:`I_3` is the 3x3 identity matrix and - :math:`t` is the translation vector. - - :math:`o` is given by the ``offset`` attribute, :math:`t` is given by the ``vector`` - attribute multiplied by the field value, and :math:`R` is defined as a rotation - about an axis in the direction of ``vector``, of angle of the field value. - - NOTE - - One possible use of ``NXtransformations`` is to define the motors and - transformations for a diffractometer (goniometer). Such use is mentioned - in the ``NXinstrument`` base class. Use one ``NXtransformations`` group - for each diffractometer and name the group appropriate to the device. - Collecting the motors of a sample table or xyz-stage in an NXtransformations - group is equally possible. - - - Following the section on the general dscription of axis in NXtransformations is a section which - documents the fields commonly used within NeXus for positioning purposes and their meaning. Whenever - there is a need for positioning a beam line component please use the existing names. Use as many fields - as needed in order to position the component. Feel free to add more axis if required. In the description - given below, only those atttributes which are defined through the name are spcified. Add the other attributes - of the full set: - - * vector - * offset - * transformation_type - * depends_on - - as needed. - -DEBUG - ===== ATTRS (//entry/sample/transformations@NX_class) -DEBUG - value: NXtransformations -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations'] -DEBUG - classes: -NXsample.nxdl.xml:/TRANSFORMATIONS -NXtransformations.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/sample/transformations/corrected_phi): -DEBUG - value: 90.0 -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME): -DEBUG - - Units need to be appropriate for translation or rotation - - The name of this field is not forced. The user is free to use any name - that does not cause confusion. When using more than one ``AXISNAME`` field, - make sure that each field name is unique in the same group, as required - by HDF5. - - The values given should be the start points of exposures for the corresponding - frames. The end points should be given in ``AXISNAME_end``. - -DEBUG - ===== ATTRS (//entry/sample/transformations/corrected_phi@depends_on) -DEBUG - value: rot_omg -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@depends_on - [NX_CHAR] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/depends_on): -DEBUG - - Points to the path to a field defining the axis on which this - depends or the string ".". - -DEBUG - ===== ATTRS (//entry/sample/transformations/corrected_phi@transformation_type) -DEBUG - value: rotation -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@transformation_type - [NX_CHAR] -DEBUG - <> -DEBUG - enumeration (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - -> translation -DEBUG - -> rotation -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - - The transformation_type may be ``translation``, in which case the - values are linear displacements along the axis, ``rotation``, - in which case the values are angular rotations around the axis. - - If this attribute is omitted, this is an axis for which there - is no motion to be specifies, such as the direction of gravity, - or the direction to the source, or a basis vector of a - coordinate frame. - -DEBUG - ===== ATTRS (//entry/sample/transformations/corrected_phi@units) -DEBUG - value: degrees -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@units [NX_TRANSFORMATION] -DEBUG - ===== ATTRS (//entry/sample/transformations/corrected_phi@vector) -DEBUG - value: [0 1 0] -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@vector - [NX_NUMBER] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/vector): -DEBUG - - Three values that define the axis for this transformation. - The axis should be normalized to unit length, making it - dimensionless. For ``rotation`` axes, the direction should be - chosen for a right-handed rotation with increasing angle. - For ``translation`` axes the direction should be chosen for - increasing displacement. For general axes, an appropriate direction - should be chosen. - -DEBUG - ===== FIELD (//entry/sample/transformations/rot_omg): -DEBUG - value: 131.7 -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME): -DEBUG - - Units need to be appropriate for translation or rotation - - The name of this field is not forced. The user is free to use any name - that does not cause confusion. When using more than one ``AXISNAME`` field, - make sure that each field name is unique in the same group, as required - by HDF5. - - The values given should be the start points of exposures for the corresponding - frames. The end points should be given in ``AXISNAME_end``. - -DEBUG - ===== ATTRS (//entry/sample/transformations/rot_omg@depends_on) -DEBUG - value: rot_phi -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@depends_on - [NX_CHAR] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/depends_on): -DEBUG - - Points to the path to a field defining the axis on which this - depends or the string ".". - -DEBUG - ===== ATTRS (//entry/sample/transformations/rot_omg@transformation_type) -DEBUG - value: rotation -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@transformation_type - [NX_CHAR] -DEBUG - <> -DEBUG - enumeration (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - -> translation -DEBUG - -> rotation -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - - The transformation_type may be ``translation``, in which case the - values are linear displacements along the axis, ``rotation``, - in which case the values are angular rotations around the axis. - - If this attribute is omitted, this is an axis for which there - is no motion to be specifies, such as the direction of gravity, - or the direction to the source, or a basis vector of a - coordinate frame. - -DEBUG - ===== ATTRS (//entry/sample/transformations/rot_omg@units) -DEBUG - value: degrees -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@units [NX_TRANSFORMATION] -DEBUG - ===== ATTRS (//entry/sample/transformations/rot_omg@vector) -DEBUG - value: [1 0 0] -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@vector - [NX_NUMBER] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/vector): -DEBUG - - Three values that define the axis for this transformation. - The axis should be normalized to unit length, making it - dimensionless. For ``rotation`` axes, the direction should be - chosen for a right-handed rotation with increasing angle. - For ``translation`` axes the direction should be chosen for - increasing displacement. For general axes, an appropriate direction - should be chosen. - -DEBUG - ===== FIELD (//entry/sample/transformations/rot_phi): -DEBUG - value: 2.5 -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME): -DEBUG - - Units need to be appropriate for translation or rotation - - The name of this field is not forced. The user is free to use any name - that does not cause confusion. When using more than one ``AXISNAME`` field, - make sure that each field name is unique in the same group, as required - by HDF5. - - The values given should be the start points of exposures for the corresponding - frames. The end points should be given in ``AXISNAME_end``. - -DEBUG - ===== ATTRS (//entry/sample/transformations/rot_phi@depends_on) -DEBUG - value: rot_tht -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@depends_on - [NX_CHAR] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/depends_on): -DEBUG - - Points to the path to a field defining the axis on which this - depends or the string ".". - -DEBUG - ===== ATTRS (//entry/sample/transformations/rot_phi@transformation_type) -DEBUG - value: rotation -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@transformation_type - [NX_CHAR] -DEBUG - <> -DEBUG - enumeration (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - -> translation -DEBUG - -> rotation -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - - The transformation_type may be ``translation``, in which case the - values are linear displacements along the axis, ``rotation``, - in which case the values are angular rotations around the axis. - - If this attribute is omitted, this is an axis for which there - is no motion to be specifies, such as the direction of gravity, - or the direction to the source, or a basis vector of a - coordinate frame. - -DEBUG - ===== ATTRS (//entry/sample/transformations/rot_phi@units) -DEBUG - value: degrees -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@units [NX_TRANSFORMATION] -DEBUG - ===== ATTRS (//entry/sample/transformations/rot_phi@vector) -DEBUG - value: [0 1 0] -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@vector - [NX_NUMBER] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/vector): -DEBUG - - Three values that define the axis for this transformation. - The axis should be normalized to unit length, making it - dimensionless. For ``rotation`` axes, the direction should be - chosen for a right-handed rotation with increasing angle. - For ``translation`` axes the direction should be chosen for - increasing displacement. For general axes, an appropriate direction - should be chosen. - -DEBUG - ===== FIELD (//entry/sample/transformations/rot_tht): -DEBUG - value: 401.18 -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME): -DEBUG - - Units need to be appropriate for translation or rotation - - The name of this field is not forced. The user is free to use any name - that does not cause confusion. When using more than one ``AXISNAME`` field, - make sure that each field name is unique in the same group, as required - by HDF5. - - The values given should be the start points of exposures for the corresponding - frames. The end points should be given in ``AXISNAME_end``. - -DEBUG - ===== ATTRS (//entry/sample/transformations/rot_tht@depends_on) -DEBUG - value: trans_z -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@depends_on - [NX_CHAR] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/depends_on): -DEBUG - - Points to the path to a field defining the axis on which this - depends or the string ".". - -DEBUG - ===== ATTRS (//entry/sample/transformations/rot_tht@transformation_type) -DEBUG - value: rotation -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@transformation_type - [NX_CHAR] -DEBUG - <> -DEBUG - enumeration (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - -> translation -DEBUG - -> rotation -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - - The transformation_type may be ``translation``, in which case the - values are linear displacements along the axis, ``rotation``, - in which case the values are angular rotations around the axis. - - If this attribute is omitted, this is an axis for which there - is no motion to be specifies, such as the direction of gravity, - or the direction to the source, or a basis vector of a - coordinate frame. - -DEBUG - ===== ATTRS (//entry/sample/transformations/rot_tht@units) -DEBUG - value: degrees -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@units [NX_TRANSFORMATION] -DEBUG - ===== ATTRS (//entry/sample/transformations/rot_tht@vector) -DEBUG - value: [0 0 1] -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@vector - [NX_NUMBER] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/vector): -DEBUG - - Three values that define the axis for this transformation. - The axis should be normalized to unit length, making it - dimensionless. For ``rotation`` axes, the direction should be - chosen for a right-handed rotation with increasing angle. - For ``translation`` axes the direction should be chosen for - increasing displacement. For general axes, an appropriate direction - should be chosen. - -DEBUG - ===== FIELD (//entry/sample/transformations/trans_x): -DEBUG - value: 2.65 -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME): -DEBUG - - Units need to be appropriate for translation or rotation - - The name of this field is not forced. The user is free to use any name - that does not cause confusion. When using more than one ``AXISNAME`` field, - make sure that each field name is unique in the same group, as required - by HDF5. - - The values given should be the start points of exposures for the corresponding - frames. The end points should be given in ``AXISNAME_end``. - -DEBUG - ===== ATTRS (//entry/sample/transformations/trans_x@depends_on) -DEBUG - value: /entry/instrument/manipulator/transformations/trans_z -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@depends_on - [NX_CHAR] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/depends_on): -DEBUG - - Points to the path to a field defining the axis on which this - depends or the string ".". - -DEBUG - ===== ATTRS (//entry/sample/transformations/trans_x@transformation_type) -DEBUG - value: translation -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@transformation_type - [NX_CHAR] -DEBUG - <> -DEBUG - enumeration (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - -> translation -DEBUG - -> rotation -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - - The transformation_type may be ``translation``, in which case the - values are linear displacements along the axis, ``rotation``, - in which case the values are angular rotations around the axis. - - If this attribute is omitted, this is an axis for which there - is no motion to be specifies, such as the direction of gravity, - or the direction to the source, or a basis vector of a - coordinate frame. - -DEBUG - ===== ATTRS (//entry/sample/transformations/trans_x@units) -DEBUG - value: mm -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@units [NX_TRANSFORMATION] -DEBUG - ===== ATTRS (//entry/sample/transformations/trans_x@vector) -DEBUG - value: [1 0 0] -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@vector - [NX_NUMBER] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/vector): -DEBUG - - Three values that define the axis for this transformation. - The axis should be normalized to unit length, making it - dimensionless. For ``rotation`` axes, the direction should be - chosen for a right-handed rotation with increasing angle. - For ``translation`` axes the direction should be chosen for - increasing displacement. For general axes, an appropriate direction - should be chosen. - -DEBUG - ===== FIELD (//entry/sample/transformations/trans_y): -DEBUG - value: -4.321 -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME): -DEBUG - - Units need to be appropriate for translation or rotation - - The name of this field is not forced. The user is free to use any name - that does not cause confusion. When using more than one ``AXISNAME`` field, - make sure that each field name is unique in the same group, as required - by HDF5. - - The values given should be the start points of exposures for the corresponding - frames. The end points should be given in ``AXISNAME_end``. - -DEBUG - ===== ATTRS (//entry/sample/transformations/trans_y@depends_on) -DEBUG - value: trans_x -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@depends_on - [NX_CHAR] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/depends_on): -DEBUG - - Points to the path to a field defining the axis on which this - depends or the string ".". - -DEBUG - ===== ATTRS (//entry/sample/transformations/trans_y@transformation_type) -DEBUG - value: translation -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@transformation_type - [NX_CHAR] -DEBUG - <> -DEBUG - enumeration (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - -> translation -DEBUG - -> rotation -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - - The transformation_type may be ``translation``, in which case the - values are linear displacements along the axis, ``rotation``, - in which case the values are angular rotations around the axis. - - If this attribute is omitted, this is an axis for which there - is no motion to be specifies, such as the direction of gravity, - or the direction to the source, or a basis vector of a - coordinate frame. - -DEBUG - ===== ATTRS (//entry/sample/transformations/trans_y@units) -DEBUG - value: mm -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@units [NX_TRANSFORMATION] -DEBUG - ===== ATTRS (//entry/sample/transformations/trans_y@vector) -DEBUG - value: [0 1 0] -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@vector - [NX_NUMBER] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/vector): -DEBUG - - Three values that define the axis for this transformation. - The axis should be normalized to unit length, making it - dimensionless. For ``rotation`` axes, the direction should be - chosen for a right-handed rotation with increasing angle. - For ``translation`` axes the direction should be chosen for - increasing displacement. For general axes, an appropriate direction - should be chosen. - -DEBUG - ===== FIELD (//entry/sample/transformations/trans_z): -DEBUG - value: 34.82 -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME): -DEBUG - - Units need to be appropriate for translation or rotation - - The name of this field is not forced. The user is free to use any name - that does not cause confusion. When using more than one ``AXISNAME`` field, - make sure that each field name is unique in the same group, as required - by HDF5. - - The values given should be the start points of exposures for the corresponding - frames. The end points should be given in ``AXISNAME_end``. - -DEBUG - ===== ATTRS (//entry/sample/transformations/trans_z@depends_on) -DEBUG - value: trans_y -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@depends_on - [NX_CHAR] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/depends_on): -DEBUG - - Points to the path to a field defining the axis on which this - depends or the string ".". - -DEBUG - ===== ATTRS (//entry/sample/transformations/trans_z@transformation_type) -DEBUG - value: translation -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@transformation_type - [NX_CHAR] -DEBUG - <> -DEBUG - enumeration (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - -> translation -DEBUG - -> rotation -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/transformation_type): -DEBUG - - The transformation_type may be ``translation``, in which case the - values are linear displacements along the axis, ``rotation``, - in which case the values are angular rotations around the axis. - - If this attribute is omitted, this is an axis for which there - is no motion to be specifies, such as the direction of gravity, - or the direction to the source, or a basis vector of a - coordinate frame. - -DEBUG - ===== ATTRS (//entry/sample/transformations/trans_z@units) -DEBUG - value: mm -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@units [NX_TRANSFORMATION] -DEBUG - ===== ATTRS (//entry/sample/transformations/trans_z@vector) -DEBUG - value: [0 0 1] -DEBUG - classpath: ['NXentry', 'NXsample', 'NXtransformations', 'NX_NUMBER'] -DEBUG - classes: -NXtransformations.nxdl.xml:/AXISNAME -DEBUG - NXtransformations.nxdl.xml:/AXISNAME@vector - [NX_NUMBER] -DEBUG - <> -DEBUG - documentation (NXtransformations.nxdl.xml:/AXISNAME/vector): -DEBUG - - Three values that define the axis for this transformation. - The axis should be normalized to unit length, making it - dimensionless. For ``rotation`` axes, the direction should be - chosen for a right-handed rotation with increasing angle. - For ``translation`` axes the direction should be chosen for - increasing displacement. For general axes, an appropriate direction - should be chosen. - -DEBUG - ===== FIELD (//entry/start_time): -DEBUG - value: b'2019-05-23T18:13:54.657000+00:00' -DEBUG - classpath: ['NXentry', 'NX_DATE_TIME'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/start_time -NXentry.nxdl.xml:/start_time -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/start_time): -DEBUG - - Datetime of the start of the measurement. - -DEBUG - documentation (NXentry.nxdl.xml:/start_time): -DEBUG - Starting time of measurement -DEBUG - ===== FIELD (//entry/title): -DEBUG - value: b'Valence Band Dynamics - 1030 nm linear p-polarized pump, 0.6 mJ/cm2 absorbed fluence' -DEBUG - classpath: ['NXentry', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/title -NXentry.nxdl.xml:/title -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/title): -DEBUG - -DEBUG - documentation (NXentry.nxdl.xml:/title): -DEBUG - Extended title for entry -DEBUG - ===== GROUP (//entry/user [NXmpes::/NXentry/NXuser]): -DEBUG - classpath: ['NXentry', 'NXuser'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/USER -NXentry.nxdl.xml:/USER -NXuser.nxdl.xml: -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/USER): -DEBUG - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - -DEBUG - documentation (NXentry.nxdl.xml:/USER): -DEBUG - -DEBUG - documentation (NXuser.nxdl.xml:): -DEBUG - - Contact information for a user. - - The format allows more - than one user with the same affiliation and contact information, - but a second :ref:`NXuser` group should be used if they have different - affiliations, etc. - -DEBUG - ===== ATTRS (//entry/user@NX_class) -DEBUG - value: NXuser -DEBUG - classpath: ['NXentry', 'NXuser'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/USER -NXentry.nxdl.xml:/USER -NXuser.nxdl.xml: -DEBUG - @NX_class [NX_CHAR] -DEBUG - -DEBUG - ===== FIELD (//entry/user/address): -DEBUG - value: b'Faradayweg 4-6, 14195 Berlin' -DEBUG - classpath: ['NXentry', 'NXuser', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/USER/address -NXuser.nxdl.xml:/address -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/USER/address): -DEBUG - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - -DEBUG - documentation (NXuser.nxdl.xml:/address): -DEBUG - Address of user -DEBUG - ===== FIELD (//entry/user/affiliation): -DEBUG - value: b'Fritz Haber Institute of the Max Planck Society' -DEBUG - classpath: ['NXentry', 'NXuser', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/USER/affiliation -NXuser.nxdl.xml:/affiliation -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/USER/affiliation): -DEBUG - - Name of the affiliation of the user at the point in time when the experiment was - performed. - -DEBUG - documentation (NXuser.nxdl.xml:/affiliation): -DEBUG - Affiliation of user -DEBUG - ===== FIELD (//entry/user/email): -DEBUG - value: b'beaulieu@fhi-berlin.mpg.de' -DEBUG - classpath: ['NXentry', 'NXuser', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/USER/email -NXuser.nxdl.xml:/email -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/USER/email): -DEBUG - - Email address of the user. - -DEBUG - documentation (NXuser.nxdl.xml:/email): -DEBUG - Email of user -DEBUG - ===== FIELD (//entry/user/name): -DEBUG - value: b'Samuel Beaulieu' -DEBUG - classpath: ['NXentry', 'NXuser', 'NX_CHAR'] -DEBUG - classes: -NXmpes.nxdl.xml:/ENTRY/USER/name -NXuser.nxdl.xml:/name -DEBUG - <> -DEBUG - documentation (NXmpes.nxdl.xml:/ENTRY/USER/name): -DEBUG - - Name of the user. - -DEBUG - documentation (NXuser.nxdl.xml:/name): -DEBUG - Name of user responsible for this entry -DEBUG - ===== FIELD (//entry/user/role): -DEBUG - value: b'Principal Investigator' -DEBUG - classpath: ['NXentry', 'NXuser', 'NX_CHAR'] -DEBUG - classes: -NXuser.nxdl.xml:/role -DEBUG - <> -DEBUG - documentation (NXuser.nxdl.xml:/role): -DEBUG - - Role of user responsible for this entry. - Suggested roles are "local_contact", - "principal_investigator", and "proposer" - -DEBUG - ======================== -DEBUG - === Default Plotable === -DEBUG - ======================== -DEBUG - -DEBUG - NXentry has been identified: /entry -DEBUG - -DEBUG - NXdata group has been identified: /entry/data -DEBUG - ===== GROUP (//entry/data [NXmpes::/NXentry/NXdata]): -DEBUG - ===== ATTRS (//entry/data@NX_class) -DEBUG - value: NXdata -DEBUG - ===== ATTRS (//entry/data@axes) -DEBUG - value: ['kx' 'ky' 'energy' 'delay'] -DEBUG - ===== ATTRS (//entry/data@delay_indices) -DEBUG - value: 3 -DEBUG - ===== ATTRS (//entry/data@energy_indices) -DEBUG - value: 2 -DEBUG - ===== ATTRS (//entry/data@kx_indices) -DEBUG - value: 0 -DEBUG - ===== ATTRS (//entry/data@ky_indices) -DEBUG - value: 1 -DEBUG - ===== ATTRS (//entry/data@signal) -DEBUG - value: data -DEBUG - -DEBUG - Signal has been identified: /entry/data/data -DEBUG - ===== FIELD (//entry/data/data): -DEBUG - value: [[[1.14760e+04 1.64560e+04 1.55440e+04 1.48940e+04 1.08810e+04] ... -DEBUG - Dataset referenced as NXdata SIGNAL -DEBUG - ===== ATTRS (//entry/data/data@units) -DEBUG - value: counts -DEBUG - -DEBUG - For Axis #0, 1 axes have been identified: [] -DEBUG - -DEBUG - For Axis #1, 1 axes have been identified: [] -DEBUG - -DEBUG - For Axis #2, 1 axes have been identified: [] -DEBUG - -DEBUG - For Axis #3, 1 axes have been identified: [] From 076b73986f9247cdc6ad0065f22bf869a0f93634 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Thu, 31 Aug 2023 18:16:43 +0200 Subject: [PATCH 18/18] pylint --- tests/dataconverter/test_convert.py | 6 ------ 1 file changed, 6 deletions(-) diff --git a/tests/dataconverter/test_convert.py b/tests/dataconverter/test_convert.py index ffeaed91c..22d7803d7 100644 --- a/tests/dataconverter/test_convert.py +++ b/tests/dataconverter/test_convert.py @@ -197,12 +197,6 @@ def test_mpes_writing(tmp_path): nexus_helper.process_nexus_master_file(None) with open(os.path.join(tmp_path, 'mpes_test.log'), 'r', encoding='utf-8') as logfile: log = logfile.readlines() - with open( - os.path.join(dirpath, 'Ref_nexus_mpes.log'), - 'r', - encoding='utf-8' - ) as logfile: - ref_log = logfile.readlines() assert len(log) == 4486